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

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2021-02-02 14:09:30

Am 02.02.21 um 13:44 schrieb Niall Douglas via Boost:
>> Reason is that Win32 needs the declspec on classes:
>> https://docs.microsoft.com/de-de/cpp/cpp/using-dllimport-and-dllexport-in-cpp-classes?view=msvc-160
> You only need dllimport for variables. If you don't apply it to types,
> MSVC "does the right thing".
Then why do the MSVC docs say otherwise? Or what am I missing from the 
posted link?
>> Could you elaborate why marking classes currently marked as BOOST_*_DECL
>> with BOOST_SYMBOL_VISIBLE would make visibility not have an effect?
>> BOOST_SYMBOL_IMPORT
> You would export an imported library's exported symbols in your own
> library's exported symbols set.
>
> If you want that, choose -fvisibility=default, because if you do as you
> suggest, it's the same thing. People asking for -fvisibility=hidden
> specifically are requesting you don't export unrelated symbols from your
> library's symbol export set. You can go ahead and do it anyway, but
> users would rightly complain that Boost is messing up their links. If
> you consider that some use a visibility hidden internal Boost to prevent
> collision with end users using their own Boost, I can foresee a bunch of
> angry users.
>
>> The exception in question is marked with BOOST_*_DECL which is empty for
>> consumers and hence hidden visibility if the consumer builds with hidden
>> visibility.
> That is a bug in ProgramOptions.
I'm either misunderstanding you are this is contradiction  what you 
wrote above. If the current behavior of expanding BOOST_*_DECL to either 
BOOST_SYMBOL_EXPORT or BOOST_SYMBOL_IMPORT when DYN_LINK is defined is 
wrong, and using BOOST_SYMBOL_VISIBLE is wrong and not using anything 
does not work per the GCC docs and experience on OSX, then what is the 
correct way?