This question would come up anytime the code is included in more than one shared library (aka DLL). Its not a serialization issue per se. I would think that for lots of reasons, code that implements a particular class should be in only one DLL in general. When using template generated code this implies a certain amount of extra consideration on the part of the programmer. But I do believe that the best (and perhaps only reliable) way to address this is to organize code modules so the problem is avoided. I have been considering the issue of serialization code in DLLS but none of the changes I would like to make address the situation you describe below. Robert Ramey "Neal Becker" <ndbecker2@verizon.net> wrote in message news:cl1i9b$581$1@sea.gmane.org...
I brought up the topic that int the current cvs serialization libs are only built static, not shared. The reason for this is that the library uses this construct: ,----[ /home/nbecker/stuff/A.hpp ] | // {{{ struct A | | struct A { | int i; | A() { i = 1; } | static const A instance; | }; | | // }}} | | extern const A A::instance = A(); `----
If this is included into 2 shared libraries, will A::instance be shared?
I have tested this on Linux. If you dlopen 2 different shared libs, it will work correctly, if you set the flags RTLD_NOW|RTLD_GLOBAL.
Since this will work correctly on some systems, I would like to see this supported.
It is impossible to use serialization with boost::python without shared libs.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost