This is the mail archive of the libstdc++@gcc.gnu.org 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] |
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.
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?
Agreed.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] |