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

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

Am 02.02.21 um 10:22 schrieb Niall Douglas via Boost:
> On 02/02/2021 08:35, Alexander Grund via Boost wrote:
>> Hi Boost maintainers,
>>
>> TLDR: Check your classes if they use BOOST_*_DECL and change that to
>> BOOST_SYMBOL_VISIBLE
> That's identical to making -fvisibility=hidden no longer have effect. So
> please Boost maintainers DO NOT DO THE ABOVE.
I was partially wrong. IMO this is a bug in Boost.Config which should 
not define BOOST_SYMBOL_IMPORT to nothing. I opened an issue to discuss 
this there: https://github.com/boostorg/config/issues/362
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 

Could you elaborate why marking classes currently marked as BOOST_*_DECL 
with BOOST_SYMBOL_VISIBLE would make visibility not have an effect?
Because this is essentially what I'm suggesting for Boost.Config: 
BOOST_*_DECL is either BOOST_SYMBOL_IMPORT or BOOST_SYMBOL_EXPORT, the 
former is (currently) empty, the latter is BOOST_SYMBOL_VISIBLE 
(disregarding Win32, see above)

Note that this es exactly what e.g. CMake does: 
https://github.com/Kitware/CMake/blob/36bb0e32d7e3976eed424078cf5cac459651f0f1/Modules/GenerateExportHeader.cmake#L309-L311

>> In Boost.ProgramOptions I discovered an issue as a user, where I was
>> unable to catch an exception thrown from the shared Boost library in an
>> executable when both are build with hidden visibility.
> As per the instructions at https://gcc.gnu.org/wiki/Visibility, all
> types requiring RTTI lookup to succeed outside their TU need to be
> marked default visibility in all translation units. If you fail to do
> this in any single translation unit, the typeinfo become hidden, and the
> RTTI lookup will silently fail.
Fully agreed so far.
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.
Marking the class with BOOST_SYMBOL_VISIBLE is fully in agreement with 
your statement, isn't it? Because currently the consumer TU won't have 
default visibility for the class.
Only Win32 must be considered too so classes should stay marked as 
BOOST_*_DECL (for the declspec) but that must not expand to nothing on 
Linux/OSX
> Myself and Dave Abrahams designed the current Boost macro markup
> according to https://gcc.gnu.org/wiki/Visibility (actually, the GCC
> documents' end was written according to what we had done in Boost, but I
> digress) and it is correct, *if Boost libraries apply the macros
> correctly* as per the guide.

What is the guide? Currently the Boost.Config documents 
BOOST_SYMBOL_VISIBLE as to be used for exceptions: 
https://github.com/boostorg/config/blob/5bcaa933b55dd58797775d87605a6cdef4acd5a2/doc/macro_reference.qbk#L1555

However this seems to be contradicting 
https://docs.microsoft.com/de-de/cpp/cpp/using-dllimport-and-dllexport-in-cpp-classes?view=msvc-160 
because BOOST_SYMBOL_VISIBLE is empty on Win32 but the classes should be 
marked declspec(dllimport/dllexport), or am I missing anything here?

Alex