Hi, On Fri, 15 Jun 2012, Gabriel Dos Reis wrote:
> On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight <f...@fuhm.net> 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. Ciao, Michael.
