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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-02-02 16:25:58

On 2/2/21 7:09 PM, Alexander Grund via Boost wrote:
> 
> 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++?

I suspect, Mac OS (more precisely, its linker) is the crucial part, not 
libc++. clang+libc++ on Linux is relatively well tested (or at least 
used to be, when Travis was more usable), but Mac OS is less tested 
because of slow turnaround.

>> 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.

For classes defined in a header, neither EXPORT nor IMPORT are needed. 
Only VISIBLE is, if you need publicly visible RTTI.