Re: [boost] ABI issues with -std

Subject: Re: [boost] ABI issues with -std
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-08-20 04:46:04

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.