[boost] Re: serialization - build shared libs

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-10-19 11:49:12

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_at_[hidden]> wrote in message
news:cl32n6$ss4$1_at_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
>