c++/3310: RTTI dynamic_cast fails for dynamic modules with common lib.

[bgreen at nas dot nasa dot gov]

>Number:         3310
>Category:       c++
>Synopsis:       RTTI dynamic_cast fails for dynamic modules with common lib.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jun 20 22:26:02 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Bryan D. Green
>Release:        3.0
>Organization:
NASA Ames Research Center
>Environment:
System: Linux pc125.nas.nasa.gov 2.4.2-2smp #1 SMP Sun Apr 8 20:21:34 EDT 2001 i686 unknown
Architecture: i686

host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /home/bgreen/gcc/gcc-3.0/configure --prefix=/usr/local/gcc-3.0 --enable-threads=posix
>Description:
    There is a problem (new to gcc-3.0) that prevents two modules from
    sharing a common "interface" (abstract class) using dynamic_cast, without
    the executable that loaded the modules having linked against the library
    that provides the "interface" definition.
    The problem seems to boil down to the two modules each having their own
    (incompatible) notion of a class's type, even though the class is
    implemented in one place (a common DSO library).

    The example is complex and cant be shown in a single file.
    I could make and provide a tar file, but other than that I'm not sure
    how you would like me to provide the example code.

    The simplest example case involves one dso library, two "modules"
    (dso's loaded with 'dlopen(dsoname,RTLD_NOW)') and one loader program.
    The library facilitates passing a base pointer between module #1 and
    module #2 - module #2 then downcasts the pointer from module #1 to a type
    implemented by the library and common to both modules.
    This downcast now fails with gcc-3.0, even though the object is of the
    expected type, and has only one definition shared by the two modules.
    Things work if the executable (the loader) happens to link against the
    same library also, but this defeats the purpose of using modules as
    independent, extensible components.

    The details:

    The library implements:
     . a polymorphic base class "IBase" (having at least one virtual
       function implemented in the library)
     . an abstract class ("LibInterface"), deriving from IBase and providing
       abstract methods (plus one or more methods may exist with
       implementations provided by the library).  This class acts as an
       interface between two modules which link against this library.
     . a set of methods by which one module can pass an 'IBase' pointer to
       another module.

    Module #1 does the following:
     . Provides an implementation of the LibInterface interface by deriving
       from LibInterface:
       ("class MyImpl : public LibInterface")
     . provides to the library an 'IBase' pointer to an instance of the
       implementation class (MyImpl).

    Module #2 does the following:
     . receives an 'IBase' pointer which was provided by Module #1.
     . downcasts the pointer from 'IBase' to 'LibInterface'.
     . tests for successful downcast (fails for gcc-3.0).

    Loader program:
     . loads the modules.
     . dlsym()'s and calls a function in Module #1 which registers the
       'MyImpl' instance.
     . dysym()'s and calls a function in Module #2 which receives the
       published 'IBase' pointer and tests it.

    class heirarchy:

           IBase        (implemented in libfoo.so)
           /
         LibInterface   (implemented in libfoo.so)
         /
        MyImpl          (implemented in mod1.so)


>How-To-Repeat:

    If you like, please tell me how you'd like to receive a tar file with
    the example code. :)

>Fix:
 unknown

>Release-Note:
>Audit-Trail:
>Unformatted: