On 8/19/2018 4:37 PM, Peter Dimov via Boost wrote:
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.
I do not think this will occur. If the shared library is statically loaded the linker will resolve the issue and tell you that Y::f(X&&) is not there at link time, and if the shared library is dynamically loaded whatever functionality which you call at run-time to get the address of Y::f(X&&) will fail. I can see the case where you expect a call to resolve to Y::f(X&&) but because the library is built as c++03 it resolves to Y::f(X const &) instead, but that is to be expected unless the end-user does not know that he is using a c++03 shared library. Of course if your program is not rebuilt against a shared library whose ABI changes you probably get a run-time error as soon as you execute code, but I would view that as user error. I am not saying that it is not a problem when a library with the same name is rebuilt with different public functionality for an end-user of that library. This can theoretically occur in much more minute ways than just changing the level of C++ standard support. Are you arguing that the final name of a Boost shared library should be different depending on its C++ standard support level ?
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.