Subject: Re: [boost] ABI issues with -std
From: Peter Dimov (lists_at_[hidden])
Date: 2018-08-19 20:37:25
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
void f( X const& x );
void f( X&& x );
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk