Antony Polukhin
GCC's Standard library and some other libraries had an issue. They were assuming that if two dynamic libraries have same strings, then dynamic linker will load those symbols to the same address. That's why they were comparing types by pointers to type names instead of comparing type names. Unfortunately assumption is not right for some platforms (ARM) and linkers.
Oh yes, I'll need to check GCC once more. As I remember that issue was fixed in GCC 4.5 and it is safe to use default std::type_info comparison.
If the following would reproduce the problem, then it has been fixed on ARM by now: [petr@trimslice-f18-v7hl tmp]$ cat lib.cc #include <typeinfo> class xx {}; std::type_info const &get_ti () { return typeid (xx); } [petr@trimslice-f18-v7hl tmp]$ g++ lib.cc -Wall -fpic -shared -o lib.so [petr@trimslice-f18-v7hl tmp]$ cat app.cc #include <cassert> #include <typeinfo> class xx {}; std::type_info const &get_ti (); int main (void) { std::type_info const &ti1 = get_ti (); std::type_info const &ti2 = typeid (xx); assert (&ti1 == &ti2); assert (ti1.name () == ti2.name ()); } [petr@trimslice-f18-v7hl tmp]$ g++ app.cc lib.so -Wall [petr@trimslice-f18-v7hl tmp]$ LD_LIBRARY_PATH=. ./a.out [petr@trimslice-f18-v7hl tmp]$ echo $? 0 [petr@trimslice-f18-v7hl tmp]$ rpm -q gcc glibc gcc-4.7.2-8.fc18.armv7hl However that might also be influenced by the dynamic linker, as that's where vague linkage is resolved. I don't know about this particular problem, so I don't know what it was caused by. Thanks, PM