public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* c++/3310: RTTI dynamic_cast fails for dynamic modules with common lib.
@ 2001-06-20 22:26 bgreen
  0 siblings, 0 replies; 2+ messages in thread
From: bgreen @ 2001-06-20 22:26 UTC (permalink / raw)
  To: gcc-gnats; +Cc: bgreen

>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:


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: c++/3310: RTTI dynamic_cast fails for dynamic modules with common lib.
@ 2001-12-15 10:01 nathan
  0 siblings, 0 replies; 2+ messages in thread
From: nathan @ 2001-12-15 10:01 UTC (permalink / raw)
  To: bgreen, gcc-bugs, gcc-prs, nobody

Synopsis: RTTI dynamic_cast fails for dynamic modules with common lib.

State-Changed-From-To: open->closed
State-Changed-By: nathan
State-Changed-When: Sat Dec 15 10:01:28 2001
State-Changed-Why:
    User error. Please read the (new) faq entry about dynamic
    cast and dynamic libraries

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3310


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-12-15 18:01 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-06-20 22:26 c++/3310: RTTI dynamic_cast fails for dynamic modules with common lib bgreen
2001-12-15 10:01 nathan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).