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.