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

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

>> Why do individual libraries now have to deal with the Windows vs 
>> non-Windows case? Is there ANY Boost library which does this?
>
> Turns out, libraries don't need to distinguish Windows from 
> non-Windows. As pointed out by Peter, BOOST_SYMBOL_EXPORT already 
> expands to BOOST_SYMBOL_VISIBLE on non-Windows.
For classes (exceptions and virtual ones) defined in the header 
BOOST_SYMBOL_VISIBLE must be used.

Peter and I found a simple way to reproduce the behavior I was seeing on 
Mac: Use libc++
`./b2 link=shared libs/program_options/test/ toolset=clang 
stdlib=libc++` is enough to reproduce the problem.

I'm actually surprised that this hasn't come up before. No tests for all 
boost with libc++?

>> Â From the BOOST_SYMBOL_VISIBLE description: "Needed for classes that 
>> are not otherwise exported, but are used by RTTI". This sounds to me 
>> like either a BOOST_SYMBOL_EXPORT or BOOST_SYMBOL_IMPORT should work.
>> Now I'm left to wonder why individual libraries must now distinguish 
>> between OSes additionally to their *_DYN_LINK.
>>
>> And if Boost.Config is correct: What does BOOST_SYMBOL_IMPORT (on 
>> non-Windows) mean then? If the default visibility is set to hidden 
>> (-fvisibility=hidden), then this macro will NOT import an exported 
>> symbol, it will create a new, private one.
>> This doesn't sound intentional.
>
> BOOST_SYMBOL_IMPORT doesn't need to expand to BOOST_SYMBOL_VISIBLE 
> when the marked symbols are only defined in the library, which is the 
> case normally. When the user consumes the library, no markup is needed 
> as the compiler will simply leave unresolved references to those 
> symbols, to be resolved by the linker.
> Â Basically, BOOST_SYMBOL_IMPORT is only there for compatibility with 
> Windows.
Agreed with the first part.
But quite many are defined in headers, especially the exceptions, so 
there it is required.
Also for exceptions with methods implemented in the cpp file you'd need 
(currently) IMPORT and VISIBLE