From mboxrd@z Thu Jan 1 00:00:00 1970 From: bgreen@nas.nasa.gov To: gcc-gnats@gcc.gnu.org Cc: bgreen@nas.nasa.gov Subject: c++/3310: RTTI dynamic_cast fails for dynamic modules with common lib. Date: Wed, 20 Jun 2001 22:26:00 -0000 Message-id: <200106210515.f5L5FGo00829@pc125.nas.nasa.gov> X-SW-Source: 2001-06/msg00871.html List-Id: >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: