On Wed, Feb 25, 2009 at 1:20 AM, Ulrich Türk
Emil Dotchevski
writes: Isn't this a problem of using the incorrect visibility options and/or dlopen flags? My plugin system (including its use of std::type_info, and including dynamic unloading) works fine on Windows and LINUX, so unless you're hitting some kind of version-specific bug, you might be doing something wrong.
Could you please describe shortly, if your plugins are compiled with specific visibility options and how you load them (dlopen flags e.g.)?
Yes, I'm using RTLD_GLOBAL.
I also encountered the reported problem. My plugin system here uses the dlopen flag RTLD_LOCAL in order keep plugins separated. Some other support libraries for loading shared objects e.g. libtldl might not support specifying this flag to RTLD_GLOBAL.
If you want certain symbols in a .so to not be visible, you can make them invisible when you build the .so; dlopen would still see everything else, including the important compiler-generated stuff like type_info objects and vtables. Reducing the visible symbols in a .so could also reduce its size.
I am strongly against using string comparisons for std::type_info objects because A) they might not work, B) if this was the right thing to do the compiler would be doing it that way (as MSVC does), and C) it would do nothing to solve the more general problem, which has to do with symbol visibility. If your std::type_info comparison is broken, then comparing function pointers and other compiler-generated objects is broken too.
A) is it due to different name mangling?
A) Is due to the C++ standard not guaranteeing you anything about what .name() returns. A standard-conforming compiler could strip out all names and return "n00b" for every type name.
B) gcc seems to do it since some time for performance reasons
All I'm saying is that operator== is the right way to compare std::type_info objects. I don't know if the only motivation for the exact behavior of operator== is performance, but I don't feel qualified to suggest to the GCC team to change it (which would be the right "fix", assuming there is a problem to fix.)
C) IMHO, function pointers and other stuff might not be interesting when just one wants to get boost::any to work across library borders.
What about virtual function table pointers? What about the rest of the
RTTI system? Would dynamic_cast