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 16:50:52

On 7/6/2010 2:58 PM, Robert Ramey wrote:
> John Maddock wrote:
>
>>> autolink code is being enabled by BOOST_HAS_DECL which is
>>> now now being used to enable "visibility". This is likely
>>> even more confused as I believe I've used this or
>>> something like it to trick the compiler/linker into
>>> suppressing code stripping of code not otherwise
>>> explicitly referred to.
>>
>> GCC's visibility feature is actually very similar to msvc's
>> import/export feature - just a different name.  Using it to
>> prevent code being stripped will continue as before for
>> msvc, and probably have no effect (as before) for gcc.

GCC's visibility varies from MSVC's dllexport/import in subtle
ways, but is largely the same in effect, but only with
-fvisibility=hidden.

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

HTH,

Rob