4 ms·

This is a flag day, though. Even the Fedora developers have said as much [1]. Had they changed the version number to add this feature, it would have caused less

This is a flag day, though. Even the Fedora developers have said as much [1]. Had they changed the version number to add this feature, it would have caused less pain for developers and distributors, because they wouldn't have to worry about what ABI to link to and who to make angry. They could have been in a position to bundle both, and tools that require delving into the deeper workings of the library, like compilers, would be better able to get the info they need. Had the GCC team done this correctly, they'd have bumped the version number, so people who depend on their software can choose to ship both versions if they want to. Instead, c++ software linked against libstdc++ is going to have a period of confusion, because both versions exist in the same library. [1] http://fedoramagazine.org/gcc-5-in-fedora-whats-an-abi-and-what-happens-when-we-change-it/ http://fedoramagazine.org/gcc-5-in-fedora-whats-an-abi-and-w...

rleigh 11y ago
The dual ABI is only implemented in libstdc++, so if you want to use the new ABI in a library then all your dependent libraries will then need to use the new ABI so you are all using the same std::string etc.. From this point of view it's perfectly sensible for a Linux distribution to decide to rebuild everything using the new ABI. You're right that a soname increment would have been one way to do this. But you would still have the problem of transitive dependencies on the old ABI since you can't load two libstdc++ libraries at the same time. In a few months time we'll all forget this was an issue since it will for all intents and purposes (for the end user and developer) be a completely transparent upgrade.