[fdo-internals] dynamic_cast and shared libraries on Linux

[Greg Boone]

Yes. I have seen this also with templated classes. 

I concur with Traian that the general rule to work around this issue has
been to use static casts where possible. Typically this is the case for
all of the FDO connection, capabilities, command, geometry interfaces,
etc. These typically have a known type associated with them. 

One aspects of the FDO API that still required dynamic casting has been
aspects of the FDO expression API since there is no associated type
information to a portion of these classes. However, I have not
encountered problems in the past in using dynamic casting in this area
of the FDO API.

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian
Stanev
Sent: Tuesday, February 20, 2007 1:03 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] dynamic_cast and shared libraries on Linux


Yeah I've seen this problem and I think others have also. We just use
static casts.

Traian


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Frank
Warmerdam (External)
Sent: Tuesday, February 20, 2007 12:43 PM
To: FDO Internals Mail List
Subject: [fdo-internals] dynamic_cast and shared libraries on Linux

Folks,

In the GDAL unit tests I am seeing some dynamic_cast failures that are
quite frustrating.

In particular this error:

  """
  7) test: 17RfpTestBandConfig.testGetNullValue1 (F) line: 32
  RfpTestBandConfig?.h

      "Unhandled FdoException? in testGetNullValue1"
  """

  Seems to be due to this dynamic_cast failing:
          FdoPtr<FdoISelect> cmdSelect = dynamic_cast<FdoISelect*>(cmd);

  cmd is in fact suitable to dynamically cast to FdoISelect, but the
actual
  class is related to FdoISelect somewhat indirectly (through several
layers
  of dirivation and use of a template).  According to the following FAQ
this
  can result in problems with dynamic cast operating across shared
library
  boundaries with gcc 3.x (or later?):

    http://www.gnu.org/software/gcc/faq.html#dso

  Changing the code to a static_cast resolves the issue.  I wonder if we
  need to require a particular version of gcc, or perhaps that we need
  to pursue some of the build options mentioned in the FAQ (which are a
  bit esoteric).  I did quickly try changing the dlopen() in
  FdoConnectionManagerto use the _GLOBAL flag but that did not seem to
  have an effect.

Has anyone else observed this sort of problem?  Are the GDAL unit tests
passing for anyone out there on linux?  If so, what version of gcc
are you using?

For the time being I'm changing the unit tests to use static_cast on
linux,
but this puts application code that uses dynamic_cast in substantial
danger.

Best regards,
--
---------------------------------------+--------------------------------
------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo,
http://osgeo.org

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals


_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals