[boost] Re: serialization - build shared libs

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-10-19 13:09:39

"Neal D. Becker" <ndbecker2_at_[hidden]> wrote in message
news:cl3j0k$kn0$1_at_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.)
>

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

> 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).

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