Subject: Re: [boost] ABI issues with -std
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-08-20 07:28:46
On 20/08/2018 16:46, Edward Diener wrote:
> On 8/19/2018 4:37 PM, Peter Dimov wrote:
>> 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
> 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.
The problem is that the headers are compiled as C++11 (because they're
included by that translation unit) while the source was compiled as C++03.
Thus this is a link error -- the header specified that the move
constructor should be present, but the compiled library does not contain it.
> 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 ?
Yes, there are a lot more things that can cause the exact same problem
-- this is one of the reasons why the Windows builds include so many
different "ABI altering" flags in their names.
Historically Linux hasn't had to worry about this as much since
"everything" is compiled from source using the same compilers and
libraries -- except when they aren't.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk