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.