On Sun, Aug 19, 2018 at 6:17 PM, Peter Dimov via Boost
At some point, we'll need to acknowledge the problem which results from building Boost with one -std and user code with another, and deal with it somehow, if just by documenting.
Most of our libraries don't suffer from it at the moment but Boost.System does, because of my changes; its ABI changes between 03/11/14. So I'm going to take the initial hit. :-)
POSIX platforms have long been able to ignore ABI issues so we don't mangle the library names there at all, but now whether one builds Boost for C++03, C++11 or C++14 matters, and there's nothing to prevent linking C++xx to C++yy. Even with --layout=versioned, the cxxstd level is not encoded.
The fact that the default C++ standard differs between g++ and clang++ doesn't help; when following the instructions of doing "b2 install", with g++6 and above you get C++14, but with g++5 or clang++ you get C++03. The latter is very rarely what one wants today.
Our libraries should build into binaries that are suitable for linking with user's code in any C++ version, otherwise standard Boost binaries in Linux distributions will be compatible only with one C++ version, which is not practical. Could you expand on what causes the ABI difference and why it can't be unified? I know it may be ugly, but libstdc++ does maintain ABI stability somehow, we could follow its example. If we can't or don't want to make Boost.System ABI-portable then I'd rather revert the changes to Boost.System and maybe create Boost.System2 for C++11 and up.