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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-02-02 17:06:23

On 2/2/21 7:40 PM, Peter Dimov via Boost wrote:
> Andrey Semashev вроте:
> 
>> 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.
> 
> Nope. libc++ on Linux also fails. Apparently, libstdc++ masks the error 
> because it uses strcmp (even for g++ 4.4 which is the earliest I test on 
> Travis.)

Am I correct that BOOST_PROGRAM_OPTIONS_DECL is defined to 
BOOST_SYMBOL_IMPORT, which expands to nothing, and it breaks when 
Boost.ProgramOptions library throws an exception marked with it?

I'm asking because I have a similar setup in Boost.Filesystem, and it is 
tested with clang+libc++ on Linux, and the tests passed last time I checked.

One potential problem that I noticed is that if an exception is marked 
with BOOST_*_DECL and static linking is enabled, BOOST_*_DECL is empty 
and the exception RTTI is left hidden. This can be a problem if the user 
links with Boost statically (e.g. wraps it into a library of his own) 
and then the exception crosses the library boundary.