|
Boost : |
Subject: Re: [boost] C++03 and C++11 ABI compatibility for compiled libraries
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-13 17:26:55
Le 13/05/13 14:08, Andrey Semashev a écrit :
> Hi,
>
> I would like to raise the issue of binary compatibility of compiled Boost
> libraries between C++03 and C++11. I faced this problem with gcc on Linux,
> but other compilers and platforms may be affected as well.
>
> To summarize the problem:
>
> * Most, if not all Linux distributions build packages in C++03 mode. This
> is also the default in gcc.
> * Some Boost libraries conditionally use C++11 features in their binary
> interfaces (see [1] as an example). This makes C++03 and C++11 versions of
> the library binary incompatible.
> * Given that, users are unable to use C++11 in their code that uses Boost
> because of linker failures.
>
> I don't have the complete list of the offending C++11 features that break
> ABI, but it would seem that at least scoped enums and rvalue references are
> among them. Are there any more?
>
> I would like to hear opinions on the possible course of action to tackle
> this problem. Currently, I see 2 choices:
>
> 1. Avoid using C++11 features in binary interfaces. This may also mean
> avoiding STL types in binary interfaces, if they differ between C++03 and
> C++11 (I didn't verify that). This is my suggested hotfix solution for
> Boost.Filesystem [1] and the approach I took in Boost.Log. Obviously, this
> cripples code and error prone, but it keeps a single binary that can be
> used from any flavor of C++ on the user's side.
> 2. Compile different versions of Boost libraries, for each supported C++
> version. The C++ version should be encoded into the library file names, so
> that different versions can coexist. This would require changes in
> Boost.Build and autolinking support code, but I think this would be a
> better long-term solution.
>
> Opinions?
>
I'm completely against option 1, it would kill Boost.
Best,
Vicente
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk