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

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

Rob Stewart wrote:

>> Hmmm - now I'm wondering about code stripping in gcc. Why is
>> this not a problem for this compiler?  Does it never strip
>> code? Does it depend on compile time switches that we don't
>> user or ???.
>
> Without that switch, GCC exposes all symbols.  That would be the
> same as if declspec(dllexport) were applied to every symbol when
> using MSVC.
>
>> To my mind, the problem is that the library depends on
>> behavior outside the scope of the C++ standard so we sort of
>> end up addressing these issues by trial and error.  It seems
>> the whole subject of runtime linking is basically undefined.
>
> It is undefined WRT the C++ Standard, but it is well defined for
> MSVC and GCC.  The issue is one of understanding the behavior of
> those two platforms, not trial and error.
>
> To further clarify GCC's visibility, note that once
> -fvisibility=hidden is used, GCC will expose no symbols by
> default.  That's equivalent to MSVC's default behavior, which is
> why declspec(dllexport)/import is needed with MSVC.  However,
> just changing the dllexport/import macros to make things visible
> for GCC isn't sufficient.  There are some symbols that MSVC
> automagically exports that GCC does not.  That means there are
> some symbols that must be marked visible for GCC that needn't
> been exported for MSVC, such as exception classes and types that
> are used in dynamic_casts.  Whether those are an issue for
> Boost.Serialization, I couldn't say.

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

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.

Robert Ramey