Hello all,
Emil Dotchevski
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.)? 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. One quick solution is: use from any.hpp unsafe_any_cast instead of any_cast Note that the signature is different; e.g. use boost::any b; ... MyClass* pClass = boost::unsafe_any_cast<MyClass>(&b); ... instead of: boost::any b; ... MyClass class = boost::any_cast<MyClass>(b); ... Read also the comments before unsafe_any_cast in any.hpp; in spite of the warning that this function is subject to change, it is still in boost 1.38.0 and it seems to be still used by boost::signal.
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? B) gcc seems to do it since some time for performance reasons C) IMHO, function pointers and other stuff might not be interesting when just one wants to get boost::any to work across library borders. Best regards, Uli