Re: [boost] ABI issues with -std

Subject: Re: [boost] ABI issues with -std
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-08-20 07:57:24

On 20/08/2018 12:42, Peter Dimov wrote:
> But in general, there's no practical way to support mixed standards 
> unless we change something in the way we do things, and I don't know 
> what. If you compile library A with C++03 and library B with C++11
> and both use shared_ptr, in a program that uses both there will be an
> ODR violation because shared_ptr will use std::atomic when present
> (in B) and will not use it when not (in A).

Pick one of:

1. Ignore the issue and let it be the user's problem.  "Don't do that." 
This is basically how things are at the moment and it's fine for people 
who build Boost themselves, but not as good for people trying to build 
or use a system-provided precompiled Boost.  ODR violations are everywhere.

2. Make everything header-only.  This doesn't solve the problem but it 
pushes it to the user like #1 (and also increases their compile times).

3. Compile once in C++03, once in C++11, etc and again for any other 
ABI-affecting Boost.Config setting the library uses (and, importantly, 
for any such things any of your *ABI-visible dependencies* use).  In the 
end, merge the result into a single compiled library (using different 
internal namespaces for each build), and have the headers select one 
implementation or the other based on the settings in effect from the caller.

4. Compile only once for whatever the user specifies but use library 
name mangling so that different library ABIs can coexist.

5. Wait for modules and hope they solve it.  (This is otherwise #1)

Some libraries are already doing a little of #3 for specific settings, 
but it probably needs to be more universal to handle things like move 
constructors, as already noted here.

One feature of #3 (which some will like and others will hate) is that it 
would allow different "islands" of C++03 and C++11 (or later) code to 
coexist, as long as they don't try to pass Boost objects in their own 
ABI between each other.  (And if they do try, they'll get a link error 
instead of an ODR violation.)