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.