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

Jeff Law law@redhat.com
Mon Jun 18 12:55:00 GMT 2012


On 06/16/2012 12:46 PM, Michael Matz wrote:
>>
> 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?
I'd like to echo this.  In my discussions shops doing large C++ 
development, they've made it clear that the disruption caused by a 
soname bump would be immense and should be avoided at all costs.


> 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.
Agreed.


It's probably worth noting that at least some of the desire to bump the 
soname expressed to me was to enable moving forward from 
-fabi-version=2.  I don't think we've seen any viable plan to get us 
away from the V2 abi without a soname bump.

jeff



More information about the Gcc mailing list