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

Subject: Re: [boost] support for gcc hidden visibility in shared libraries
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-12-06 16:39:29

Stjepan Rajko wrote:
> On Sat, Dec 6, 2008 at 4:37 AM, Andrey Semashev
> <andrey.semashev_at_[hidden]> wrote:
>>
>> 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).

Agreed.

> 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

We could support both by introducing a build switch to control visibility.
AFAIK, the common practice for other build toolsets is to keep the
default build settings as close to compiler defaults as possible, so the
default visibility mode should be the default (argh.. too many defaults
in this sentence!). The restricted visibility (be that ms-compat or
inlines-hidden) could be enabled with the build switch.