3 ms·

Just gcc produced ones. GCC wanted to add a feature so that developers can add and change functions without changing the library version number. Which, to be qu

Just gcc produced ones. GCC wanted to add a feature so that developers can add and change functions without changing the library version number. Which, to be quite honest, is a silly feature, as it leads to problems like the one we're seeing right here.

rleigh 11y ago
GCC libstdc++ has been backward compatible with no ABI breaks for around a decade. GNU libc for what, two decades. You don't break such fundamental ABIs on a whim. If the libstdc++ ABI had changed, it would have broken every single bit of C++ code built with GCC4 over the last decade. Including code with transitive dependencies on the old ABI. Rather than declaring this as a "silly feature", I think we might be better off thanking the developers concerned for solving a very hard problem and going the extra mile to ensure backward compatibility. They could have been lazy and said "ABI break! Flag day today: every user of GCC much rebuild the entire world and, by the way, none of your old software will run any longer", but they didn't. So clang hasn't got the new ABI quite right to match GCC, that's a minor niggle. It can be fixed. You can't fix breaking the whole world. As an example, consider that the Mesa OpenGL C library internally uses libstdc++. If this was built using an incompatible new ABI, it would break every C++ program linked against the old ABI. And vice-versa. That game or expensive visualisation software you bought, that's not going to work any more. Stable ABIs matter.
- nly 11y ago
  Well said. I was using Gentoo around the GCC 3.3 -> 3.4 migration (that's when the ABI last broke seriously). That wasn't fun.
- Sanddancer 11y ago
  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.

rleigh 11y ago

GCC libstdc++ has been backward compatible with no ABI breaks for around a decade. GNU libc for what, two decades. You don't break such fundamental ABIs on a whim. If the libstdc++ ABI had changed, it would have broken every single bit of C++ code built with GCC4 over the last decade. Including code with transitive dependencies on the old ABI. Rather than declaring this as a "silly feature", I think we might be better off thanking the developers concerned for solving a very hard problem and going the extra mile to ensure backward compatibility. They could have been lazy and said "ABI break! Flag day today: every user of GCC much rebuild the entire world and, by the way, none of your old software will run any longer", but they didn't. So clang hasn't got the new ABI quite right to match GCC, that's a minor niggle. It can be fixed. You can't fix breaking the whole world. As an example, consider that the Mesa OpenGL C library internally uses libstdc++. If this was built using an incompatible new ABI, it would break every C++ program linked against the old ABI. And vice-versa. That game or expensive visualisation software you bought, that's not going to work any more. Stable ABIs matter.

nly 11y ago
Well said. I was using Gentoo around the GCC 3.3 -> 3.4 migration (that's when the ABI last broke seriously). That wasn't fun.
Sanddancer 11y ago
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.