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