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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk