Why do individual libraries now have to deal with the Windows vs non-Windows case? Is there ANY Boost library which does this?
Turns out, libraries don't need to distinguish Windows from non-Windows. As pointed out by Peter, BOOST_SYMBOL_EXPORT already expands to BOOST_SYMBOL_VISIBLE on non-Windows. For classes (exceptions and virtual ones) defined in the header BOOST_SYMBOL_VISIBLE must be used.
From the BOOST_SYMBOL_VISIBLE description: "Needed for classes that are not otherwise exported, but are used by RTTI". This sounds to me like either a BOOST_SYMBOL_EXPORT or BOOST_SYMBOL_IMPORT should work. Now I'm left to wonder why individual libraries must now distinguish between OSes additionally to their *_DYN_LINK.
And if Boost.Config is correct: What does BOOST_SYMBOL_IMPORT (on non-Windows) mean then? If the default visibility is set to hidden (-fvisibility=hidden), then this macro will NOT import an exported symbol, it will create a new, private one. This doesn't sound intentional.
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
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++? there it is required. Also for exceptions with methods implemented in the cpp file you'd need (currently) IMPORT and VISIBLE