[jcelerier]

Let me quote exactly the page you linked :

> The GNU C++ compiler, g++, has a compiler command line option to switch between various different C++ ABIs. This explicit version switch is the flag -fabi-version.

If you want to target a given distro, you -fabi-version this distro's ABI, just like you set -mmacosx-version-min on mac or set _WIN32_WINNT on windows

[rumanator]

That's something that might be useful for one of those rare end-users who for some reason want to try to build something with a bleeding edge compiler.

That is also mind-numbingly absurd to force upon the vast majority who couldn't care less about the bleeding edge and want a stable platform to act as a fixe target without risking random ABI breakages.

I should not be forced to endure a brittle and fragile and overly-complex compilation process just because a random guy somewhere had a whim about taking a compiler out for a spin.

The world expects stability. If you wish to try out some stuff, just download the compiler and build the damn thing yourself. Hell, odds are that there's already a PPA somewhere. So where's the need to screw over everyone?

[gpderetta]

The ABI (the itanium ABI) is fixed, but somtimes there are bug in the compiler and gcc deviates from the abi in some corner cases. When the bug is fixed the gcc abi version is bumped which most of the time doesn't matter but if the bug fix affects you (and very often it doesn't), you can 'roll it back' by selecting a specific ABI version. Not fixing the bug is not an option because it means that GCC would be incompatible with other compilers that don't have the bug.

[rumanator]

> ABI (the itanium ABI) is fixed,

That's irrelevant. The only aspect that is relevant is that the C++ standard does not define nor assume a standard or even fixed ABI, thus each compiler vendor just goes with the flow.

In some rare cases where a compiler vendor also controls the platform and essentially holds a vertically integrated monopoly, they are in a better position to not break the ABI all that often. Everyone else doing stuff in C++, whether writing programs or libraries or compilers or putting together OS distributions, just faces the music.

[jcelerier]

> That is also mind-numbingly absurd to force upon the vast majority who couldn't care less about the bleeding edge and want a stable platform to act as a fixe target without risking random ABI breakages.

but why would you have "random ABI breakages" ? there isn't any issue with using e.g. VS2010, 2012, 2015, 2017, 2019 to make a windows software for instance, so what makes you think Linux would be any different if you could install a compiler version of your choosing instead of the one fixed by Ubuntu / Debian / whatever. Why is it a problem for C/C++ but not for Go / Rust / every other native-compiled language in the universe ?

[rumanator]

> there isn't any issue with using e.g. VS2010, 2012, 2015, 2017, 2019

You're conflating things and in the process making absurd comparisons. Windows is not Linux and GCC is not msvc++. GCC is very vocal on how they don't support ABI compatibility, and Microsoft was very vocal ensuring they enforce ABI compatibility from Visual Studio 2015 onward. There's a fundamental difference in multiple dimensions, which isn't bridged by mindlessly stating that GCC and mscv are both compilers.

ABI is the bane of C++. Why are you posting comments on a thread about C++ and the problems created by ABI if you are oblivious to this? The only thing you're managing to do is generate noise and make everyone waste their time with your posts.

> so what makes you think Linux would be any different

Because it is, and at many levels. Just the fact that you are entirely oblivious to this basic fact is enough to convince anyone not to bother with any further replies to this thread.

[gpderetta]

> GCC is very vocal on how they don't support ABI compatibility,

What? Apart from bugs, GCC has maintained backward compatibility for more than a decade, for both the compiler ABI and the standard library.

They were forced to break ABI for c++11 to implement the new string and list semantics, but the old ABI is still available.

[jcelerier]

> Windows is not Linux and GCC is not msvc++

That does not mean anything. Linux can be whatever people with enough free time want it to be. It's 100% possible to imagine a Linux-based system with a Windows-like userspace and pacing. Hell, technically you could just ship the Linux kernel, an init system, Wine and live in an almost windows-y world - even cl.exe works under wine.

> Why are you posting comments on a thread about C++ and the problems created by ABI if you are oblivious to this?

Because it's an entirely self-inflicted problem, caused by putting toolchains (among two thousand other things) in distros.

Again, why do people have no trouble shipping Rust which has zero ABI guarantees to ten year old Ubuntus and C++ couldn't ? The answer is, it totally can if you just let it and let go of shipping dev packages in distros, instead relying on C++-specific package managers such as conan or vcpkg for your dependencies.

I build my own software with latest versions of clang, Qt, boost and have no trouble distributing it to fairly old distros.

> Because it is, and at many levels.

yes, I'm asking about what could be, not what is ?

[jfkebwjsbx]

> GCC is very vocal on how they don't support ABI compatibility

Source? They very rarely break ABI. They even release ABI break fixes sometimes.

> Microsoft was very vocal ensuring they enforce ABI compatibility from Visual Studio 2015 onward.

They try to keep ABI stable, but nothing is promised until the actual releases happen.

Always expect a new ABI version at some point in the future!