Subject: Re: [boost] C++03 and C++11 ABI compatibility for compiled libraries
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-05-13 16:47:25
On Monday 13 May 2013 15:35:06 Michael Marcin wrote:
> On 5/13/13 12:21 PM, Andrey Semashev wrote:
> > On Monday 13 May 2013 18:26:38 Klaim - JoÃ«l Lamotte wrote:
> >> On Mon, May 13, 2013 at 5:29 PM, Michael Marcin
> > <mike.marcin_at_[hidden]>wrote:
> >>> Does boost ever claim support for abi compatibility with different
> >>> compiler settings? I thought not.
> >> I thought boost explicitely, somewhere, stated that binary compatibility
> >> is
> >> not a requirement for libraries.
> >> I remember it being the main argument for developing "booster" which is a
> >> "fixed" set of boost libraries used in CPPCMS.
> > I think that was about binary compatibility between different releases of
> > Boost or its libraries. It's a bit different from compatibility between
> > single release builds for different C++ versions.
> > Speaking of different releases, Boost does mangle library names with the
> > release version, so linked applications will always use the correct
> > binaries. This counts in favor for the solution (2), with mangling
> > library names differently in C++03 and C++11.
> There are also parameters where the names do not encoding important
> settings. If the code is compiled for x86 or x64 for instance. The user
> is just expected to build and use the libraries they need.
Libraries for different architectures are installed into different system
folders, so it's not a problem.
Surely there are compiler options that affect ABI and do not get encoded in
the file names. Things like stack alignment and calling conventions are far
from being commonly changed in projects, and if they are people know the
caveats. C++ flavor is another kind of option. You should typically _expect_
more and more people enable C++11, despite the fact it's not the default on
current systems. And, IMHO, Boost should honor and help that trend.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk