Re:Re: [boost] Re: serialization - build shared libs
Martin Ecker wrote:
Neal Becker wrote:
Is this perhaps a MS-windows specific problem? I did build a shared lib (using scons, I haven't learned jam yet), and AFAICT it is working, on Linux.
I'm pretty sure you will also run into problems with shared objects under Linux. The problem is that certain global variables (e.g. for the type registry) are defined as static member variables in header files. Under Windows, if two different DLLs include this header file, you will get two different copies of that static member variable - one in each DLL - although there should only be one. Maybe the linker under Linux is smart enough to resolve such issues.
Have you tried to serialize a class defined in one shared object (which is registered in the type registry via BOOST_CLASS_EXPORT) from code in another shared object? That's when you might run into problems. You definitely will under Windows.
You might also run into problems when you dynamically (i.e. explicitly in your code via dlopen) load a shared object, which contains classes that use BOOST_CLASS_EXPORT to register themselves. Again, under Windows you definitely will.
I think there is a little confusion here about what it means to build the serialization library as a Shared Library or DLL. a) if you mean creating libraries which contain exactly the same functionality as libboost_serialiation.lib and libboost_wseralization.lib then there should be no problem as far as I know. Note that you might have problems if you loading/unloading the shared libraries multiple times under program control. I'm not sure. I haven't tested this and have left it for latter. Mainly this is because it should use the ABI autolink to be line with other boost libraries and work better for users. b) if you creating DLLS which instantiate serialization templates for specific classes - then you most likely have problems. There are still some issues pending. Martin has jumped ahead and addressed these issues for his application and most of his additions will likely eventually find their way into the serialization library in some form. Robert Ramey
Robert Ramey wrote:
a) if you mean creating libraries which contain exactly the same functionality as libboost_serialiation.lib and libboost_wseralization.lib then there should be no problem as far as I know. Note that you might have problems if you loading/unloading the shared libraries multiple times under program control. I'm not sure. I haven't tested this and have left it for latter. Mainly this is because it should use the ABI autolink to be line with other boost libraries and work better for users.
So will serialization build dlls by default when 1.32 ships? I've just started to build it with bcc32 and currently use auto-link which forces everything to be a dll (due to thread requiring to be a dll on win32 in 1.31). Thanks Russell
I have successfully built serialization as dlls under bcc32 by duplicating the two 'lib' sections in the JamFile and renaming them to dll and then adding the <dll>libboost_serialization and <dll>libboost_wserialization to the install and stage sections. Could this be done in the JamFile before 1.32.0 is released? Thanks Russell Russell Hind wrote:
So will serialization build dlls by default when 1.32 ships? I've just started to build it with bcc32 and currently use auto-link which forces everything to be a dll (due to thread requiring to be a dll on win32 in 1.31).
Thanks
Russell
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hello, Russell Hind wrote:
I have successfully built serialization as dlls under bcc32 by duplicating the two 'lib' sections in the JamFile and renaming them to dll and then adding the <dll>libboost_serialization and <dll>libboost_wserialization to the install and stage sections.
Unfortunately, simply building boost::serialization as DLL under Windows is not enough because the extended RTTI objects for a class are duplicated in each module/DLL. This is because the static extended type info instances are defined in header files, and under Windows this will cause an instance to be created for each module that includes that header file. This effectively means that serializing a class defined in one DLL from another DLL will not work properly. I've made some changes to boost::serialization that allow DLL builds and allow using the library with modules/DLLs (even when they are explicitly loaded/unloaded multiple times), but these changes have not yet made it into CVS. Regards, Martin TAB Austria Haiderstraße 40 4052 Ansfelden Austria Phone: +43 7229 78040-218 Fax: +43 7229 78040-209 E-mail: martin.ecker@tab.at http://www.tab.at
martin.ecker@tab.at wrote:
Hello,
Russell Hind wrote:
I have successfully built serialization as dlls under bcc32 by duplicating the two 'lib' sections in the JamFile and renaming them to dll and then adding the <dll>libboost_serialization and <dll>libboost_wserialization to the install and stage sections.
Unfortunately, simply building boost::serialization as DLL under Windows is not enough because the extended RTTI objects for a class are duplicated in each module/DLL. This is because the static extended type info instances are defined in header files, and under Windows this will cause an instance to be created for each module that includes that header file.
This effectively means that serializing a class defined in one DLL from another DLL will not work properly. I've made some changes to boost::serialization that allow DLL builds and allow using the library with modules/DLLs (even when they are explicitly loaded/unloaded multiple times), but these changes have not yet made it into CVS.
Thanks! I suggest support for building shared libs even without the changes, because from my limited testing, it will work on some systems. (Don't penalize working systems because some others don't work)
martin.ecker@tab.at wrote:
This effectively means that serializing a class defined in one DLL from another DLL will not work properly. I've made some changes to boost::serialization that allow DLL builds and allow using the library with modules/DLLs (even when they are explicitly loaded/unloaded multiple times), but these changes have not yet made it into CVS.
Is this the same issue? I don't really want to use serialization as shared library, or access it from shared libraries, I only want to use it as a lib, but we also use boost thread which, on win32, currently forces us to build and link everything as dlls so our single exe becomes a single exe but with a multitude of boost dlls shipped with it (filesystem, thread) etc. So that is why I need serialization as a dll because auto-link decides to use the dll. Currently, I'm foce-linking to the static lib (libboost-serialization-bcb-mt-d_1_31.lib) and the stuff is working but I'd rather auto-link just picked up which dll to use as the rest of boost does. Cheers Russell
Russell Hind wrote:
Currently, I'm foce-linking to the static lib (libboost-serialization-bcb-mt-d_1_31.lib) and the stuff is working but I'd rather auto-link just picked up which dll to use as the rest of boost does.
Actually, auto-link doesn't appear to be working for serialization and even if I force link against the DLLs I've built for serialization, I get a load of unresolved externals. Cheers Russell [Linker Error] Unresolved external 'boost::archive::basic_xml_iarchive<boost::archive::xml_iarchive>::load_start(const char *)' referenced from C:\USERS\RUSSELL\PROJECTS\TPICOATINGSCAN\SERVICEINTERFACE\BUILD\MAINFORM.OBJ [Linker Error] Unresolved external 'boost::archive::basic_xml_iarchive<boost::archive::xml_iarchive>::load_end(const char *)' referenced from C:\USERS\RUSSELL\PROJECTS\TPICOATINGSCAN\SERVICEINTERFACE\BUILD\MAINFORM.OBJ [Linker Error] Unresolved external 'boost::archive::xml_iarchive_impl<boost::archive::xml_iarchive>::load(_STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char> >&)' referenced from C:\USERS\RUSSELL\PROJECTS\TPICOATINGSCAN\SERVICEINTERFACE\BUILD\MAINFORM.OBJ [Linker Error] Unresolved external 'boost::archive::xml_iarchive_impl<boost::archive::xml_iarchive>::~xml_iarchive_impl<boost::archive::xml_iarchive>()' referenced from C:\USERS\RUSSELL\PROJECTS\TPICOATINGSCAN\SERVICEINTERFACE\BUILD\MAINFORM.OBJ [Linker Error] Unresolved external 'boost::archive::basic_text_iprimitive<_STL::basic_istream<char, _STL::char_traits<char> >
::~basic_text_iprimitive<_STL::basic_istream<char, _STL::char_traits<char> > >()' referenced from C:\USERS\RUSSELL\PROJECTS\TPICOATINGSCAN\SERVICEINTERFACE\BUILD\MAINFORM.OBJ [Linker Error] Unresolved external 'boost::archive::detail::basic_iarchive::~basic_iarchive()' referenced from C:\USERS\RUSSELL\PROJECTS\TPICOATINGSCAN\SERVICEINTERFACE\BUILD\MAINFORM.OBJ [Linker Error] Unresolved external 'boost::archive::xml_iarchive_impl<boost::archive::xml_iarchive>::xml_iarchive_impl<boost::archive::xml_iarchive>(_STL::basic_istream<char, _STL::char_traits<char> >&, unsigned int)' referenced from C:\USERS\RUSSELL\PROJECTS\TPICOATINGSCAN\SERVICEINTERFACE\BUILD\MAINFORM.OBJ [Linker Error] Unresolved external 'boost::archive::basic_xml_iarchive<boost::archive::xml_iarchive>::load_override(boost::archive::version_type&, int)' referenced from C:\USERS\RUSSELL\PROJECTS\TPICOATINGSCAN\SERVICEINTERFACE\BUILD\MAINFORM.OBJ [Linker Error] Unresolved external 'boost::archive::basic_xml_iarchive<boost::archive::xml_iarchive>::load_override(boost::archive::object_id_type&, int)' referenced from C:\USERS\RUSSELL\PROJECTS\TPICOATINGSCAN\SERVICEINTERFACE\BUILD\MAINFORM.OBJ [Linker Error] Unresolved external 'boost::archive::basic_xml_iarchive<boost::archive::xml_iarchive>::load_override(boost::archive::class_id_type&, int)' referenced from C:\USERS\RUSSELL\PROJECTS\TPICOATINGSCAN\SERVICEINTERFACE\BUILD\MAINFORM.OBJ [Linker Error] Unresolved external 'boost::archive::xml_iarchive_impl<boost::archive::xml_iarchive>::load_override(boost::archive::class_name_type&, int)' referenced from C:\USERS\RUSSELL\PROJECTS\TPICOATINGSCAN\SERVICEINTERFACE\BUILD\MAINFORM.OBJ [Linker Error] Unresolved external 'boost::archive::basic_xml_iarchive<boost::archive::xml_iarchive>::load_override(boost::archive::tracking_type&, int)' referenced from C:\USERS\RUSSELL\PROJECTS\TPICOATINGSCAN\SERVICEINTERFACE\BUILD\MAINFORM.OBJ [Linker Error] Unresolved external 'boost::serialization::detail::extended_type_info_typeid_0::type_info_key' referenced from C:\USERS\RUSSELL\PROJECTS\TPICOATINGSCAN\SERVICEINTERFACE\BUILD\MAINFORM.OBJ [Linker Error] Unresolved external 'boost::serialization::extended_type_info::self_register()' referenced from C:\USERS\RUSSELL\PROJECTS\TPICOATINGSCAN\SERVICEINTERFACE\BUILD\MAINFORM.OBJ [Linker Error] Unresolved external 'boost::archive::detail::basic_iarchive::load_object(void *, const boost::archive::detail::basic_iserializer&)' referenced from C:\USERS\RUSSELL\PROJECTS\TPICOATINGSCAN\SERVICEINTERFACE\BUILD\MAINFORM.OBJ
Russell Hind wrote:
I have successfully built serialization as dlls under bcc32 by duplicating the two 'lib' sections in the JamFile and renaming them to dll and then adding the <dll>libboost_serialization and <dll>libboost_wserialization to the install and stage sections.
Could this be done in the JamFile before 1.32.0 is released?
Thanks
Russell
Russell Hind wrote:
So will serialization build dlls by default when 1.32 ships? I've just started to build it with bcc32 and currently use auto-link which forces everything to be a dll (due to thread requiring to be a dll on win32 in 1.31).
The issue is not whether you can build dll, but whether it will actually work correctly.
This discussion reveals why I haven't addressed the issue yet. Here is my analysis. There are two different situations: a) A DLL which contains the same code as the libboost_serialization.lib and libboost_wserialization.dll . I see this a no problem and just a question of making the changes required to implement AUTOLIB in accordance with the instructions on the boost website. This would work exactly as the current system and have no repercussions that I know of. b) A dll that contains serialization functions related to a users classes. This is an entirely different situation than that of a) above. This has several aspects: i) If the DLL containing serialization for a given class X is loaded at the beginning of program operation and not unloaded until program termination there should be no problem. ii) if the DLL is loaded and unloaded dynamically, it will not currently work without changes to the library. The changes are doable but perhaps a little intricate. iii) if code for the same class is included in multiple DLL's there could also be problems. These are probably addressable with the changes referred to in ii) above. My view is that this situation would cause problems in areas other than serialization. Neal's original example which started this discussion is a case in point. The concept of having the same code in different DLLS seems to raise questions about undefined behavior. Adding things like static class variables makes it even more ambiguous in my mind. This is an area ripe with un-intended consequences. So my strategy has been to: a) add no functionality pending release of 1.32. Of course if I had known that branching would be 3 months after the originally scheduled time, I might have continued adding functionality a little longer. My main motivation is that this library (as well as other boost libraries) have to have reliability as absolutely number one priority. b) release 1.32 c) add AUTOLIB support and test with DLL versions of libboost_?serialization.dll d) augment code to permit dynamic loading/unloading of DLLS which include class serialization code. Intricate to code, very hard to test on multiple platforms - especially when one doesn't have these platforms available locally. e) augment manual to describe the pitfalls of including the same code in separate DLLS and promote the idea that source code and build should be organized to prevent this from happening. Of course anyone is free to tweak there own copy and get ahead of me on this. But I believe that considerations of portability and robustness require me to move at a more deliberate pace. Robert Ramey "Neal D. Becker" <ndbecker2@verizon.net> wrote in message news:cl32n6$ss4$1@sea.gmane.org...
Russell Hind wrote:
I have successfully built serialization as dlls under bcc32 by duplicating the two 'lib' sections in the JamFile and renaming them to dll and then adding the <dll>libboost_serialization and <dll>libboost_wserialization to the install and stage sections.
Could this be done in the JamFile before 1.32.0 is released?
Thanks
Russell
Russell Hind wrote:
So will serialization build dlls by default when 1.32 ships? I've just started to build it with bcc32 and currently use auto-link which forces everything to be a dll (due to thread requiring to be a dll on win32 in 1.31).
The issue is not whether you can build dll, but whether it will actually work correctly.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
a) A DLL which contains the same code as the libboost_serialization.lib and libboost_wserialization.dll . I see this a no problem and just a question of making the changes required to implement AUTOLIB in accordance with the instructions on the boost website. This would work exactly as the current system and have no repercussions that I know of.
I've done this by just adding the <dll> sections to the jamfile, and manual linking, but get unresolved externals as mentioned in a previous message. Is there more I need to do to build it as a DLL? Thanks Russell
Robert Ramey wrote:
a) A DLL which contains the same code as the libboost_serialization.lib
and
libboost_wserialization.dll . I see this a no problem and just a question of making the changes required to implement AUTOLIB in accordance with
http://www.boost.org/libs/config/config.htm in the section macros for libraries with separate source code describes what has to be done. Its not hard, it just has to be done and tested. Your procedure may work, but the above points to the boost way of addressing this. Robert Ramey "Russell Hind" <rh_gmane@mac.com> wrote in message news:cl3hp3$gip$1@sea.gmane.org... the
instructions on the boost website. This would work exactly as the current system and have no repercussions that I know of.
I've done this by just adding the <dll> sections to the jamfile, and manual linking, but get unresolved externals as mentioned in a previous message. Is there more I need to do to build it as a DLL?
Thanks
Russell
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
The complete test I did is this: ,----[ /disk1/nbecker/stuff/A.hpp ] | // {{{ struct A | | struct A { | int i; | A() { i = 1; } | static const A instance; | }; | | // }}} | | extern const A A::instance = A(); `---- ,----[ /disk1/nbecker/stuff/A.cc ] | #include <boost/python/module.hpp> | #include <boost/python/def.hpp> | #include <boost/python/class.hpp> | #include <boost/python/init.hpp> | #include <boost/python/reference_existing_object.hpp> | #include "A.hpp" | | namespace python = boost::python; | | int get() { return int(&A::instance); } | | BOOST_PYTHON_MODULE(A) | { | python::def ("get", &get); | } `---- ,----[ /disk1/nbecker/stuff/B.cc ] | #include <boost/python/module.hpp> | #include <boost/python/def.hpp> | #include <boost/python/class.hpp> | #include <boost/python/init.hpp> | #include <boost/python/reference_existing_object.hpp> | #include "A.hpp" | | namespace python = boost::python; | | int get() { return int(&A::instance); } | | BOOST_PYTHON_MODULE(B) | { | python::def ("get", &get); | } `---- I believe A.hpp captures the condition that Robert Ramey is concerned about (correct me if I'm wrong). I build A.so and B.so. Then use python to import A and B. The test is to verify that A.get() == B.get(), which shows that A::instance has the same address in both cases. This shows that both A.so and B.so are sharing the same object, which I believe satisfies the requirements. Note this is only true if you manually set python to use RTLD_GLOBAL when importing. I would argue that the ambiguities of behaviour of dlls on various OSes (and even different versions of the same OS) are issues outside of boost. Those who use dlls on various platforms should already know the issues involved. I understand the urge for caution, but I don't agree with the conclusion. Can we at least allow the building of shared libs with a small edit to some config file, so those of us using a platform that would work, at least for some usages, can do so with minimal effort? I, for one, am not familiar with boost-jam, and I don't know what files to tweak. (Right now, I am building with scons with shared libs being built into my own local dir.) I test on linux/x86 and linux/x86_64. On linux/x86 you can AFAIK link a shared lib against a static lib, so there is no issue - but on linux/x86_64 you can only link shared libs with other shared libs (as is true also on hpux IIRC).
"Neal D. Becker" <ndbecker2@verizon.net> wrote in message news:cl3j0k$kn0$1@sea.gmane.org...
The complete test I did is this:
,----[ /disk1/nbecker/stuff/A.hpp ] | // {{{ struct A | | struct A { | int i; | A() { i = 1; } | static const A instance; | }; | | // }}} | | extern const A A::instance = A(); `----
,----[ /disk1/nbecker/stuff/A.cc ] | #include <boost/python/module.hpp> | #include <boost/python/def.hpp> | #include <boost/python/class.hpp> | #include <boost/python/init.hpp> | #include <boost/python/reference_existing_object.hpp> | #include "A.hpp" | | namespace python = boost::python; | | int get() { return int(&A::instance); } | | BOOST_PYTHON_MODULE(A) | { | python::def ("get", &get); | } `---- ,----[ /disk1/nbecker/stuff/B.cc ] | #include <boost/python/module.hpp> | #include <boost/python/def.hpp> | #include <boost/python/class.hpp> | #include <boost/python/init.hpp> | #include <boost/python/reference_existing_object.hpp> | #include "A.hpp" | | namespace python = boost::python; | | int get() { return int(&A::instance); } | | BOOST_PYTHON_MODULE(B) | { | python::def ("get", &get); | } `----
I believe A.hpp captures the condition that Robert Ramey is concerned about (correct me if I'm wrong).
I build A.so and B.so. Then use python to import A and B. The test is to verify that A.get() == B.get(), which shows that A::instance has the same address in both cases. This shows that both A.so and B.so are sharing the same object, which I believe satisfies the requirements. Note this is only true if you manually set python to use RTLD_GLOBAL when importing.
I think this is basically correct. By putting the definition in a *.cc file you only end up with one. I'm more concerned about generated templates.
I would argue that the ambiguities of behaviour of dlls on various OSes (and even different versions of the same OS) are issues outside of boost. Those who use dlls on various platforms should already know the issues involved. I understand the urge for caution, but I don't agree with the conclusion. Can we at least allow the building of shared libs with a small edit to some config file, so those of us using a platform that would work, at least for some usages, can do so with minimal effort? I, for one, am not familiar with boost-jam, and I don't know what files to tweak. (Right now, I am building with scons with shared libs being built into my own local dir.)
I test on linux/x86 and linux/x86_64. On linux/x86 you can AFAIK link a shared lib against a static lib, so there is no issue - but on
LOL - a huge (disproportional) part of making a boost library is dealing with and reconciling things "outside of boost". This iincludes standard libraries (e.g. wchar_t/local support), differning conformance to standard (e.g. two phase lookup), compiler bugs (e.g. your favorite here), etc. So if one want's his library to be widely used, he must address a huge amount of things "outside of boost" - not to mention "outside his library". Its a fact of life that I suspect is waaaaaaayyyyy underappreciated by aspiring library authors. Its incredibly difficult to "finish" a boost library. So I believe that its possible to use serialization code in a DLL. I also believe that it may entail some unintended consequences that I'm not prepared to address on a case by case basis. So - feel free to do it - but remember you're plowing new ground for now. I am curious as to the results of the these efforts. Martin Ecker's efforts in this area have result in him getting exactly what he wants in this area (for Windows Platforms) and at the same time given me much helpful information. This information is reflected in my implementation strategy referred to previously. Robert Ramey linux/x86_64
you can only link shared libs with other shared libs (as is true also on hpux IIRC).
windows has issues in that there are different versions of c runtime libraries - dynamic and static. The two can't be mixed in the same program and DLLS have to use the dynamic version. This may not necessarily be an issue in other environments. Robert Ramey
You mean this? ,----[ /disk1/nbecker/stuff/A.hpp ] | // {{{ struct A | | template<class i_type> | struct A { | i_type i; | A() { i = 1; } | static const A instance; | }; | | // }}} | | template<class i_type> | extern const A<i_type> A<i_type>::instance = A(); | | template<> | extern const A<int> A<int>::instance = A<int>(); `---- ,----[ /disk1/nbecker/stuff/A.cc ] | #include <boost/python/module.hpp> | #include <boost/python/def.hpp> | #include <boost/python/class.hpp> | #include <boost/python/init.hpp> | #include <boost/python/reference_existing_object.hpp> | #include "A.hpp" | | namespace python = boost::python; | | int get() { return int(&A<int>::instance); } | | BOOST_PYTHON_MODULE(A) | { | python::def ("get", &get); | } `---- ,----[ /disk1/nbecker/stuff/B.cc ] | #include <boost/python/module.hpp> | #include <boost/python/def.hpp> | #include <boost/python/class.hpp> | #include <boost/python/init.hpp> | #include <boost/python/reference_existing_object.hpp> | #include "A.hpp" | | namespace python = boost::python; | | int get() { return int(&A<int>::instance); } | | BOOST_PYTHON_MODULE(B) | { | python::def ("get", &get); | } `---- python Python 2.3.4 (#1, Aug 31 2004, 11:13:54) [GCC 3.4.1 20040815 (Red Hat 3.4.1-9)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import sys import dl sys.setdlopenflags (dl.RTLD_GLOBAL|dl.RTLD_NOW) import A import B A.get() -155365500 B.get() -155365500
that's what I mean. Now suppose your A.hpp is included in two different *.cpp files that are used to create two different DLLS? When linking statically, the duplicate instances can be eliminated. For DLLs the link is done at run time so this is not possible. As far as I know, the results are undefined in this situation and mostly likely vary between os environments. Your test suggests that for your environment gcc/linux this is all resolved automagically which I have to concede leaves me impressed. Still, to fully support this idea, changes in the library would be required to update some internal structures when a DLL is unloaded. As I said before, this is certainly doable - doing in such a way as to avoid making the library implementation even more obscure will require some effort. And of course, your little bit of dl.RTLD_GLOBAL|dl.RTLD_NOW will have to be added to the reference manual. if anyone wants to do this work let me know. Robert Ramey "Neal D. Becker" <ndbecker2@verizon.net> wrote in message news:cl3n84$2me$1@sea.gmane.org...
You mean this? ,----[ /disk1/nbecker/stuff/A.hpp ] | // {{{ struct A | | template<class i_type> | struct A { | i_type i; | A() { i = 1; } | static const A instance; | }; | | // }}} | | template<class i_type> | extern const A<i_type> A<i_type>::instance = A(); | | template<> | extern const A<int> A<int>::instance = A<int>(); `---- ,----[ /disk1/nbecker/stuff/A.cc ] | #include <boost/python/module.hpp> | #include <boost/python/def.hpp> | #include <boost/python/class.hpp> | #include <boost/python/init.hpp> | #include <boost/python/reference_existing_object.hpp> | #include "A.hpp" | | namespace python = boost::python; | | int get() { return int(&A<int>::instance); } | | BOOST_PYTHON_MODULE(A) | { | python::def ("get", &get); | } `---- ,----[ /disk1/nbecker/stuff/B.cc ] | #include <boost/python/module.hpp> | #include <boost/python/def.hpp> | #include <boost/python/class.hpp> | #include <boost/python/init.hpp> | #include <boost/python/reference_existing_object.hpp> | #include "A.hpp" | | namespace python = boost::python; | | int get() { return int(&A<int>::instance); } | | BOOST_PYTHON_MODULE(B) | { | python::def ("get", &get); | } `---- python Python 2.3.4 (#1, Aug 31 2004, 11:13:54) [GCC 3.4.1 20040815 (Red Hat 3.4.1-9)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import sys import dl sys.setdlopenflags (dl.RTLD_GLOBAL|dl.RTLD_NOW) import A import B A.get() -155365500 B.get() -155365500
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote: [...]
Still, to fully support this idea, changes in the library would be required to update some internal structures when a DLL is unloaded.
I don't see unload/reload as a requirement. I think this use case would be pretty obscure. What semantics would you even expect in that case? I would be really happy if we at least make the common case work.
Hello, Neal D. Becker wrote:
I don't see unload/reload as a requirement. I think this use case would be pretty obscure. What semantics would you even expect in that case?
Actually, one of the reasons I invested time to make serialization work in DLL form and with serialization code in user DLLs was exactly because we have DLLs that are loaded/unloaded explicitly at runtime. A typical example could be a server that loads specific plugin modules during runtime (and can unload them again). Or in our case, we have a plugin for 3ds max that uses boost::serialization to write out data for our main application. 3ds max plugins must support dynamic loading/unloading during runtime. The semantics I expect in this case is that the classes in the newly loaded DLL that have serialization code register their extended type info with the global boost::serialization type registry, and upon unloading unregister it again. We've been using our modified version of boost::serialization ever since the draft release #18 in a rather large software system that consists of a large number of DLLs (all with serialization code, of which some are dynamically loaded/unloaded during runtime), and haven't had any major problems with it so far. Regards, Martin TAB Austria Haiderstraße 40 4052 Ansfelden Austria Phone: +43 7229 78040-218 Fax: +43 7229 78040-209 E-mail: martin.ecker@tab.at http://www.tab.at
participants (4)
-
martin.ecker＠tab.at -
Neal D. Becker -
Robert Ramey -
Russell Hind