
The Case of GCC-5.1 and the Two C++ ABIs - ingve
http://allanmcrae.com/2015/06/the-case-of-gcc-5-1-and-the-two-c-abis/
======
pbiggar
I really love the Go has gone with static binaries. There are so few use cases
where we really need to be distributing libraries separately from apps and
link them dynamically later. It's 2015, static binaries only takes a tiny bit
of memory (relative to how much is available and what we use for other
things), and both disk space and bandwidth for downloading binaries is pretty
abundant. Why are we still worrying about ABIs!!

[edit: clarified it isn't about the type of linking, it's about separate
distribution of libs from apps that use the libs).

~~~
ksherlock
static linking won't prevent this problem.

Consider a build where clang (c++11), gcc5 (c++11), and gcc4 (c++03) are used.
gcc5 uses the new abi, gcc4 uses the old abi, clang uses the new abi headers
but links to the old abi (since it doesn't yet support the new name mangling
scheme).

~~~
pcwalton
Exactly. The problem is _linking_ , not dynamic linking.

~~~
pbiggar
Yes.

------
bluejekyll
Did the ABI break for all libraries of C++11 or is it just gcc produced ones?

~~~
Sanddancer
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
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.

~~~
Sanddancer
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-w...](http://fedoramagazine.org/gcc-5-in-fedora-whats-an-abi-and-what-
happens-when-we-change-it/)

~~~
rleigh
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.

------
DannyBee
Interestingly, this was a suggestion made many many years ago and started as
an experiment. Like 10 years ago, i believe ;)

libc++ is also versioned using namespaces, but no abi_tag

------
haberman
Would love to see some more background on this. Is it the C++11 ABI itself
that changed, or just the ABI of libstdc++ when compiled as C++11?

~~~
DSMan195276
My understanding is that supporting C++11 requires changes to libstdc++
(Specifically, how std::string and std::list are implemented) which will make
the new implementation incompatible with code compiled for older versions of
libstdc++.

~~~
rleigh
You are correct that C++11 required changes to certain implementation details
of libstdc++. However, you are incorrect about this making the new
implementation incompatible with old code compiled against older libstdc++
versions; this is explicitly and intentially supported via a dual ABI--the
"new" libstdc++ will provide both the old and new variants simultaneously.

~~~
DSMan195276
Sorry, I wasn't trying to imply the new libstdc++ wouldn't work with old code,
just explaining to the poster why the new ABI is required in the first place.
The changes to libstdc++ which are incompatible are what is causing the dual
ABI to be required - And of course, the dual ABI is what allows old programs
to continue to use the old ABI with a newer libstdc++ library without
problems.

