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

Subject: Re: [boost] auto-link with gcc/windows
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2010-07-06 22:53:07

On 7/6/2010 7:11 PM, Robert Ramey wrote:
>
> Let me expand a little bit on the issue of code-stripping
> which cost me a huge amount of hassle to find a way around.
>
> a) build and test seriialization library in debug mode.
> b) everything works great
> c)  build and test in release mode - uh oh - tests using
 > exported pointers fail. But only with MSVC.
> d) After some investigation, it's determined that code not
> explicitly referred to is being stripped.
> e) After lot's of experimentation, it's found we can mark the
> functions as dll_export to be sure they are not dropped.
> These are not functions in the library, but rather templates
> instantiated inside the user's code.  MSVC uses this to
> implement Automation where one application can use COM to call
> into one application from another.
> f) This workaround was "codified" in
> boost/serialization/force_include.hpp"
> g) This problem never arose with gcc.  I'm not sure whether
> this is because gcc doesn't do any code stripping or what.

By default, GCC exposes all symbols, so it wouldn't have stripped 
anything.

> Now I'm wondering if one builds with gcc in release mode with
> visibility=hidden, if we'll get a whole rash of test
> failures.

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

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

___
Rob