Re: [boost] auto-link with gcc/windows

Subject: Re: [boost] auto-link with gcc/windows
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-07-07 01:19:31

Rob Stewart wrote:
> On 7/6/2010 7:11 PM, Robert Ramey wrote:

> It is certainly possible as there may well be things that must be
> marked visible that don't need to be exported for MSVC.  That is,
> you've identified everything that must be exported to make MSVC
> happy, but there may yet be other things to mark visible when
> using GCC's -fvisibility=hidden.
>
> Note that GCC's visibility applies to class templates, too,
> because static data members of class templates must be marked
> visible to avoid multiple definitions in shared  objects and
> referenced separately (violating the ODR, of course).

lol - yet another facet.  The serialization library instantiates
static variables for each exported type.  Depending on how
the user distributes his code among DLLS and main module
there can be multiple instances of this.  Currently this is being
trapped by the library as a possible violation of ODR with
no real guarenteed that the code in the different DLLS have
the same same implemenation version.  For now I've just
commented out the assertion which traps this, but seems
like an accident waiting to happen so in the future I expect
to re-enable the trap and and permit users to override it.
I believe this behavior has occurred on both MSVC and
gcc - but I could be wrong.

>> I'm not sure I really have a point here.  It just seems that
>> this is going to take more time than one would expect  to
>> play itself out.
>
> Perhaps, but it shouldn't be too significant.  There may be some
> help in comparing the exports from the DLL with the strong
> symbols visible in the DSO.
>
> Finally, I should have mentioned, in case you weren't aware of
> it, that BOOST_SYMBOL_VISIBLE is available for marking things
> visible that needn't (or shouldn't) be marked with
> __declspec(dllexport).

All this really caught me by surprise.  Is there any documentation on this?
Is there a comprehensive set of tests to verify how this works in different
compilers?  Seems to me there are a number of interrelated facets.

a) visibility
b) code stripping
c) handling of the same instantiated code in different modules
d) interaction with auto-linking (through shared macro names)
e) at least 3 different compilers which have at least slight differences
(MSVC, gcc, Borland, and ?)
f) at least as far as I know - no guidence from the C++ standard.
g) our testing regimen doesn't really test all combinations - debug/release
dll/lib, auto-lib/no-autolib, in a comprehensive and systematic
way.  So we can't know when we've really got it right.

I've had to spend a lot of time on all of the above.  It was in an
ad hoc / piecemeal fashion which was not at all satisfactory.  So sorting
all this out is a very worthwhile task.  But I can't help thinking that the 
scope
of this issue and size of the task has been underestimated.

Robert Ramey