This is the mail archive of the
mailing list for the GCC project.
operator==(const type_info&) failure with shared libs
- From: Ron <ron at debian dot org>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 29 Oct 2003 00:41:01 +1030
- Subject: 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)