Re: [boost] support for gcc hidden visibility in shared libraries

Subject: Re: [boost] support for gcc hidden visibility in shared libraries
From: Stjepan Rajko (stjepan.rajko_at_[hidden])
Date: 2008-12-06 11:03:20

On Sat, Dec 6, 2008 at 4:37 AM, Andrey Semashev
<andrey.semashev_at_[hidden]> wrote:
>
> If we are targeting to support -fvisibility=hidden in the end, we should
> provide two sets of macros for symbol exporting. One will have the
> semantics near to dllexport on Windows and the second will only have the
> impact when -fvisibility=hidden is in action. This is needed, for
> example, for header-only exception classes. Such classes do not need
> dllexport on Windows, but they do need default visibility on Linux.
>
> Personally, I'd rather not support -fvisibility=hidden at all, since,
> IMO, this mode is too dangerous and doesn't give much compared to
> -fvisibility-ms-compat. I think, the patch from Alexander should be
> modified to use -fvisibility-ms-compat on GCC 4.3 and up and
> -fvisibility-inlines-hidden on GCC 4.1 to 4.3. It should not restrict
> visibility at all on GCC prior to 4.1. This way we will make use of this
> feature while being on the safe side.
>

I guess there are three issues at hand:
1) which scenarios are supported by boost.config macros
2) which scenarios are supported by individual boost libraries
3) which scenario is used as the default build for boost libraries

There is little harm in supporting both scenarios (hidden / ms-compat)
as far as 1. goes.  Alexander's patch already provides macros for the
ms-compat case.  As far as 2 goes, it would seem reasonable to make
each library that can be built as shared at least support ms-compat,
and more if the author wants to.  The patch from Alexander should
already make all affected libraries support ms-compat (the tests he
reported failing with e.g., serialization, were tested with hidden,
but might pass with ms-compat).  As far as 3 goes, now that I
understand the issue a little bit more, it does seem like
visibility-hidden is *not* the correct choice.  The two reasonable
choices are:

* make the default build use default visibility, because that is the
default behavior for the platform.
* make the default build use -fvisibility-ms-compat (or at least
-fvisibility-inlines-hidden, as appropriate), to make behavior as
consistent as possible between the different platforms

Best,

Stjepan