"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