Andrey Semashev wrote:
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.
I don't think that it's possible in general to support linking any C++ version to any other. Suppose for instance that you have struct X; struct Y { void f( X const& x ); #if !defined(BOOST_NO_CXX11_RVALUE_REFERENCES) void f( X&& x ); #endif }; If you compile everything with C++03, it works. If you compile everything with C++11, it works. If you compile the library with C++11 and the user code with C++03, it works (barring other issues.) But if you compile the library with C++03, and the user code with C++11, it doesn't. The user code tries to call Y::f(X&&), and it's not there. And if you're saying that fine, we need to build the library with C++11 then, well that's part of my point, that "b2 install" builds with C++03 by default on Clang. Now the above is a trivial case, there are many other examples of code that could change depending on whether a feature is supported or not; and even when it 'works', it's still technically an ODR violation because the definition of Y is not the same. Being "ABI-portable" under a strict interpretation of the standard means that nothing in the user-facing headers is allowed to depend on whether a feature is supported or not. That's impractical. The only supported configuration, under said strict interpretation, is when everything is compiled with the same -std level. This applies even to libraries that do nothing differently by themselves, if they include a header-only library that does something differently. In practice, the present situation with Boost.System is that you can link 03 to 11, 11 to 03, 03 and 11 to 14, but not 14 to 03 or 11. This was the best I could do.