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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk