This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

operator==(const type_info&) failure with shared libs


Howdy,

Having searched around before screaming bug, I found this:

http://gcc.gnu.org/ml/gcc/2002-05/msg01970.html

As roughly similar to the behaviour I'm seeing.  You don't need to be
playing games with plugins though.

The problem appears to be that if two shared libraries, which both contain
a vague linkage symbol to a type_info object for some type T, link with an
executable that does not contain that symbol (because it doesn't contain
any code that would trigger generation of a type_info for T), then two
discrete type_info objects are maintained for T, and the simple pointer
comparison of __name in operator== fails when comparing the type_info of
objects not instantiated by the same library.

This is readily done in practice if both libraries instantiate a common
class template that makes use of typeid (or dynamic_cast etc) and pass
objects of that type between them.


If the executable also includes the typeinfo for T symbol, then
everything resolves just fine to a single reference.

The latter means I can 'fix' this, by putting forward declarations of
any template classes that might undergo typeid comparisons or
dynamic_cast'ing across library boundaries in one of the library
headers that I know the executable will include, but that hardly seems
elegant if those decl's aren't otherwise needed.


I can further work around this in the template classes that compare
typeid's by simply strcmp'ing the names myself (slower but sure to
work), but the ones where dynamic_cast erroneously fails (because the
rtti data appears unrelated) cannot be fixed with a userland hack.


Anyway, it seems like there is some prior art on this, though I couldn't
find anything more recent on the subject.  If this failure is unexpected
to somebody and/or you'd like a better explanation, I'll scrape up some
time to put a small test cast together.

cheers,
Ron

  (please cc on any reply, I'm not on this list)

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.2/specs
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.2 (Debian)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]