boost::any, type_info, and dynamically loaded libraries
I couldn't find any reference to this in the mailing list archives, so I apologize if this is a rehash. Synopsis: I'm experiencing a problem when I try to any_cast a value of an enumeration type while inside code that's part of a dynamically loaded library. I have one library that defines an enumeration. I have an application that packages up a value of this enumeration type into a boost::any. The application then dynamically loads yet another library and passes this any to a function in the newly loaded library. However, when the code in the DL library tries to any_cast the enumeration value out of the any, I receive a bad_any_cast exception. I've instrumented the any_cast code and have verified that the type_info.name() strings for both the stored and requested types are the same. However, the operator== for the type_info's is still returning false. As far as I know, type_info comparison across dynamically loaded libraries should work as long as operator== is used. Does anyone have any idea if this is a compiler issue (as I think it is)? Has anyone else experienced this kind of issue? Here's some system info that may be relevant: g++ 4.1.0 linux 2.6.16.13-4-smp (SuSE 10's default kernel) boost 1.32.0 binutils 2.16.91.0.5-18 -- Austin Bingham
boost-users-bounces@lists.boost.org schrieb am 17.10.2006 18:18:36:
I've instrumented the any_cast code and have verified that the type_info.name() strings for both the stored and requested types are the same. However, the operator== for the type_info's is still returning false.
I'm not sure if that's quite the same problem, but I had similar symptoms with two python extension modules (which are shared libraries, too). The point was that the type_info seemed to be the same, i.e. type_info.name(), but there still were two different instances around. Unfortunately, the compiler does not compare the type_info.name() but the addresses of the instances. See: http://wiki.python.org/moin/boost.python/CrossExtensionModuleDependencies The solution was to link the shared libraries with vague linkage enabled: http://gcc.gnu.org/onlinedocs/gcc/Vague-Linkage.html HTH Bernhard ___________________________________________________________________ Disclaimer: Diese Mitteilung ist nur fuer die Empfaengerin / den Empfaenger bestimmt. Fuer den Fall, dass sie von nichtberechtigten Personen empfangen wird, bitten wir diese hoeflich, die Mitteilung an die ZKB zurueckzusenden und anschliessend die Mitteilung mit allen Anhaengen sowie allfaellige Kopien zu vernichten bzw. zu loeschen. Der Gebrauch der Information ist verboten. This message is intended only for the named recipient and may contain confidential or privileged information. If you have received it in error, please advise the sender by return e-mail and delete this message and any attachments. Any unauthorised use or dissemination of this information is strictly prohibited.
You should link your executable with --export-dymanic and pass RTLD_GLOBAL to dlopen call. By doing this you stick together identical symbols from executable and dll (e.g. typeinfo). HTH, Roman Perepelitsa.
participants (3)
-
Austin Bingham -
bernhard.maeder＠zkb.ch -
Roman Perepelitsa