This is the mail archive of the
mailing list for the libstdc++ project.
Re: C++98/C++11 ABI compatibility for gcc-4.7
- From: Michael Matz <matz at suse dot de>
- To: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Cc: Gabriel Dos Reis <gdr at integrable-solutions dot net>, James Y Knight <foom at fuhm dot net>, Jonathan Wakely <jwakely dot gcc at gmail dot com>, jyasskin at googlers dot com, gcc at gcc dot gnu dot org
- Date: Sat, 16 Jun 2012 20:46:20 +0200 (CEST)
- Subject: Re: C++98/C++11 ABI compatibility for gcc-4.7
- References: <email@example.com> <CAH6eHdQEciws3XiV_mbLDaL4OA3c1B91sYH1=3OOEsK8+NhhYQ@mail.gmail.com> <firstname.lastname@example.org> <CAAiZkiAB7d5pEaKwqjR=rVt=wDa8n=zQdegOZn8HWi+M1jcemail@example.com>
On Fri, 15 Jun 2012, Gabriel Dos Reis wrote:
> On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight <firstname.lastname@example.org> wrote:
> > IMO, at the /very least/, libstdc++ should go ahead and change std::string
> > to be the new implementation. Once std::string is ABI-incompatible between
> > the modes, there's basically no chance that anyone would think that
> > linking things together from the two modes is a good thing to try, for
> > more than a couple minutes.
Careful. I find the (perhaps only perceived) enthusiasm for a soname bump
most troublesome. Are you sure you have every ABI/API-incompatible change
fully rolled out, implemented and tested already? As some c++ maintainers
still claim that c++11 is considered experimental and incomplete I somehow
doubt that. But if you do a soname change now you don't want to change it
the next 10 years (better more).
A soname change for a basic system library is a _major_ PITA and should be
avoided even at large costs. In that light: do you have a plan of action
of how to never change the soname again, at least on targets where that is
reasonably possible with symversions?
In fact, as we already use symversions also for libstdc++, a soname bump
should be avoidable already now. Perhaps requiring some extensions to
mangling, or giving the "new" classes a different assembler name for
mangling purposes, or simply via the new namespace (I'm not sure that
solves all issues). But even implementing special magic in the compiler
usable by the library to control its ABI/API would be worthwhile if a
soname bump can be avoided.