5 ms·

Itanium ABI is the de facto ABI standard. It's not developed by a single "compiler" but a collaboration of multiple compiler vendors. It works across basically

Itanium ABI is the de facto ABI standard. It's not developed by a single "compiler" but a collaboration of multiple compiler vendors. It works across basically all Unix/Linux platforms, even Windows. GCC broke the ABI and not "changed it to libstdc++" and that was more than 10 years ago with introduction of C++11 - it's a very rare occassion and exactly the reason why we can have nice and open things in Unices without worrying that software will suddenly break. Mistakes do slip from time to time such as the recent one with LLVM (15) starting to emulate SSE2 when one is not available on the HW but the code makes explicit use of it. Again, such things are rather an exception and my understanding is that Apple chooses quite the opposite strategy - they break their ABI much more often. I see that only as an annoyance which generates unnecessary extra work to keep your code running. I also think that it makes it somewhat impossible to use vanilla clang and mix it with apple-clang binaries. It's a PITA from developer PoV.

ninkendo 3y ago
I meant “changed libstdc++’s ABI”, not changed to libstdc++. ABI doesn’t just mean calling conventions defined in things like Itanium’s spec. It also means name mangling, size of structs, and many other things. Think “if I make a shared lib and compile it, and a bunch of programs link to it dynamically at runtime, what changes to the lib can break those programs after the fact, if they don’t recompile?” The answer ends up being a lot. Again, remember that supporting new C++ features means adding things to libc++, which is linked at runtime, so you don’t want to mess it up. Again, I don’t just mean “change the ABI of arbitrary code emitted by the compiler”, I mean the particular exported symbols in the particular implementation of libc++, which is dynamically linked. If they decide to add one extra field to a struct exported by that lib, then oops, they broke ABI. You don’t want to mess this up and you want it to be stable before letting people use it.
- menaerus 3y ago
  I think I have a good understanding what ABI is. The point I am trying to make is that the theory you have doesn't add up to the facts - you mention Apple as more cautious around the changes they make but the reality is that they break the ABI much more often than other vendors.

ninkendo 3y ago

I meant “changed libstdc++’s ABI”, not changed to libstdc++. ABI doesn’t just mean calling conventions defined in things like Itanium’s spec. It also means name mangling, size of structs, and many other things. Think “if I make a shared lib and compile it, and a bunch of programs link to it dynamically at runtime, what changes to the lib can break those programs after the fact, if they don’t recompile?” The answer ends up being a lot. Again, remember that supporting new C++ features means adding things to libc++, which is linked at runtime, so you don’t want to mess it up. Again, I don’t just mean “change the ABI of arbitrary code emitted by the compiler”, I mean the particular exported symbols in the particular implementation of libc++, which is dynamically linked. If they decide to add one extra field to a struct exported by that lib, then oops, they broke ABI. You don’t want to mess this up and you want it to be stable before letting people use it.

menaerus 3y ago
I think I have a good understanding what ABI is. The point I am trying to make is that the theory you have doesn't add up to the facts - you mention Apple as more cautious around the changes they make but the reality is that they break the ABI much more often than other vendors.