This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++98/C++11 ABI compatibility for gcc-4.7


On Fri, 15 Jun 2012, Gabriel Dos Reis wrote:

> On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight <> 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.
> Agreed.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]