One of the core ideas of working with LTS is that you can build your software on an LTS release and ship it to somebody else on the same LTS release, either as a source or as a binary.
If you want the latest GCC, that's fine, you're not forced to use the default compiler distributed with your OS. But it doesn't make sense to update the default compiler used in an LTS release. If you want that, then you don't want LTS.
eh, no. the OS package manager is for sysadmins. LTS is for sysadmins to not have to worry about versions changing under their feet rapidly when they apply security updates.
If you want to develop an application, you use your own toolchain. But yes I know most C++ people don't d this because C++ tools don't easily support it. But that's on C++ for not having pyenv, rustup, multiruby, etc equivalent.
> One of the core ideas of working with LTS is that you can build your software on an LTS release and ship it to somebody else on the same LTS release, either as a source or as a binary.
Yes, and updating compilers don't prevent that at all. You can use GCC 10 to ship code that will build and run on Ubuntu 12.04 without issues. Xcode 11 can ship code that works back to macOS 10.6 and Visual Studio 2019 can still optionally target windows fucking XP !
> [...] and updating compilers don't prevent that at all.
This is incorrect. In practice, for larger code bases, upgrading to a newer version of GCC or Clang is something that must be done purposefully, and you must test.
Sometimes it turns out that your code relies on some compiler behavior which has changed. Sometimes newer compilers are stricter than older compilers. There are plenty of real-world cases of these problems!
> Xcode 11 can ship code that works back to macOS 10.6 [...]
There are a number of features that are specific to the macOS toolchain which make this possible. Take a look at the "-mmacosx-version-min" flag on the macOS compiler. This selectively enables and disables various APIs. These features don't solve all the compatibility problems, either.
> Visual Studio 2019 can still optionally target windows fucking XP !
We're talking about Linux here. The Windows toolchain is radically different.
> Sometimes it turns out that your code relies on some compiler behavior which has changed.
In practice this can be "undefined behavior" like dangling pointers or data races. Maybe the new version of the compiler happens to reorder a couple of instructions (which it's perfectly within it's rights to do) which turns a "benign" race into a crash or an exploitable security issue. Is it your fault for writing these bugs? Sure. But if you're a big organization, and you know you have bugs like this, is this a reason not to upgrade your compiler? Absolutely. All the real world testing you've done on your current binaries has value, and losing some of that value needs to be weighed against the benefits of upgrading.
> This is incorrect. In practice, for larger code bases, upgrading to a newer version of GCC or Clang is something that must be done purposefully, and you must test.
Sometimes it turns out that your code relies on some compiler behavior which has changed. Sometimes newer compilers are stricter than older compilers. There are plenty of real-world cases of these problems!
So if you hit issues, do what you do on every other system which is "installing older Xcode / Visual Studio" ? That would not be an issue at all if the toolchain wasn't vendored as part of the distro, you'd just have something like rustup that allows you to use whatever version of the toolchain your project requires.
> There are a number of features that are specific to the macOS toolchain which make this possible. Take a look at the "-mmacosx-version-min" flag on the macOS compiler. This selectively enables and disables various APIs.
> We're talking about Linux here. The Windows toolchain is radically different.
what I'm saying is exactly that the Linux desktop world would be in a far better place if Linux followed the Windows / macOS way of vendoring toolchains.
The only thing that is an actual issue on Linux if you want backward compatibility is glibc which does not have an easy way (AFAIK) to say "I want to target this old glibc version". But that's not the issue for what we are talking about which is "getting newer compilers on a given distro" - Red Hat & derivatives manage this without issue with the various devtoolsets for instance.
> So if you hit issues, do what you do on every other system which is "installing older Xcode / Visual Studio" ? That would not be an issue at all if the toolchain wasn't vendored as part of the distro, you'd just have something like rustup that allows you to use whatever version of the toolchain your project requires.
Or you could switch to LTS, which achieves the same thing.
Some software packages even break between distro releases.
The primary value of a distro is to provide a fixed platform that application developers and users can safely target. Risking ABI breakups just because a rare number of users wish to be on the bleeding edge without wanting to do any of the work to install their own software is something that's very hard to justify.
> 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
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?
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.
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.
> 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 ?
> 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.
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 ?
Compiling gcc is actually not so bad (and sometimes necessary if you want to e.g. use drd to debug openmp, so you can make libgomp use pthreads primitives that drd knows how to do deal with).
If you are a dev then you can prefer using an LTS flavor of Ubuntu with a PPA for whatever you need to be newer. For important stuff this PPA are provided by Canonical so I run newer kernel and nvidia drivers on an older LTS.
You might want LTS and upgrade some packages when needed/forced and not play the "update" lottery. New updates not only bring you cool new feature and fixes , they bring new bugs and sometimes features are removed or GUIs are moved around. At least with my LTS I worked around for existing bugs , upgraded from PPA the things I needed to, browsers are latest versions and my IDE is auto-updating too.
Stable base. I'm pretty fond of Ubuntu LTS as the OS running the bare metal, then [docker] containers on top of that to run applications, which means I can have as new of apps as I want while keeping a nice boring stable kernel/bootloader/sshd/whatever.
I'm not sure I understand. You want a stable host system without the need for forced, sometimes breaking, upgrades - so an lts release "on the outside".
You want to develop with new tooling, so a newer release under lxd/lxc. But you probably want to deploy on an lts release - maybe the one comming in a year?
You could of course develop under arch in lxd/lxc - then validate for an lts release once your code is "done".
But I don't think you'd generally would want to deploy to arch - as you'd have to play catch-up in order to keep up with security patches (or backport yourself)?
