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:
> 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
>> Could you elaborate why marking classes currently marked as BOOST_*_DECL
>> with BOOST_SYMBOL_VISIBLE would make visibility not have an effect?
> 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk