Re: Wrong class export/visibility setting for shared libs in many Boost libs

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-02-02 15:20:05

On 2/2/21 5:05 PM, Niall Douglas via Boost wrote:
> On 02/02/2021 13:02, Andrey Semashev via Boost wrote:
>> On 2/2/21 3:34 PM, Niall Douglas via Boost wrote:
>>> On 02/02/2021 11:51, Andrey Semashev via Boost wrote:
>>>
>>>> So, the bottom line, BOOST_PROGRAM_OPTIONS_DECL must be defined to:
>>>>
>>>> - BOOST_SYMBOL_EXPORT - on Windows, when the library is being built;
>>>> - BOOST_SYMBOL_IMPORT - on Windows, when the library is being consumed
>>>> by user;
>>>> - BOOST_SYMBOL_VISIBLE - in any other case.
>>>
>>> This causes Boost.ProgramOptions symbols to be exported in any shared
>>> object or executable which links in Boost.ProgramOptions i.e. you
>>> reexport the same symbols.
>>
>> It does not because the symbols to be exported are (supposed to be) only
>> defined in Boost.ProgramOptions library.
> 
> BOOST_SYMBOL_VISIBLE is always default visibility, no matter what.

Right. But it applies to the symbol definition. If there is no 
definition then it has no effect.

> Therefore anything in a Boost.ProgramOptions header would be made
> visible and thus exported, which equals exporting all the extern
> declarations. That, in turn, would cause ABI collision if somebody tries
> linking in a non-matching Boost, under the assumption that an internal
> Boost has been hidden from linkage (which "works", so far).

Linking non-matching Boost versions is not supported and should be 
assumed to not work, ever. Public visibility or not. Therefore, this is 
not a valid use case.