Am 02.02.21 um 17:25 schrieb Andrey Semashev via Boost:
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.
The above command which tests Boost.ProgramOptions using clang + libc++ on Linux shows the same failure I see on OSX due to using DECL instead of VISIBLE on the exception class defined in the header. So this setting is obviously untested, which I find odd. IIRC OSX uses libc++ too which explains the correlation.
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.
Ok great, so we have a few actual bugs now: Not using VISIBLE for those. Next issue are classes declared in the header and defined in a cpp file which should be (able to be) caught by consumers. Due to the definition in the CPP I think they need the DECL (->EXPORT/IMPORT) but also VISIBLE. For comparison again: CMake defines the IMPORT macro to VISIBLE, so that's a datapoint at least: https://github.com/Kitware/CMake/blob/36bb0e32d7e3976eed424078cf5cac459651f0...