Boost logo

Boost :

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

> 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


Boost list run by bdawes at, gregod at, cpdaniel at, john at