Boost logo

Boost :

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 );
>    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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at