Re:Re: [boost] Re: serialization - build shared libs

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-09-07 23:32:21

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