This is the mail archive of the 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


Having searched around before screaming bug, I found this:

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.


  (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]