Linux users: What version of glibc and libstdc++ is everyone on?

[athenian200]

I've been using GCC 7 on Oracle Linux 7 for Epyrus builds on Linux since I started them (mostly due to inertia and an "if it ain't broke, don't fix it" mentality with regards to an OS I don't run as a daily driver), and I'm starting to think it's time for an upgrade to Oracle Linux 8. I've neglected to update the GCC version because I've been figuring I will do that when I move to a newer base OS, but now things are really getting to the point where I ought to upgrade GCC on the current OL7 box (which I am not sure is a good idea), or carry out that plan.

The problem is that if I do this, the minimum version of glibc required to run Epyrus will go from 2.17, to 2.28. I checked to see how that affects Debian builds, and that would unfortunately mean anyone on Debian 8 or 9 (or forks of them) would be unable to run Epyrus. Debian 10 would become the new minimum.

I guess what I'm wondering is, would it be fine to move to a newer environment, or are there still a lot of people running glibc 2.17? If there are in fact a lot of people running older glibc, I can try to find some kind of workaround to keep this going a bit longer.

If this is done, it probably won't be the very next release, but the one after that. There will still be one more release on the current setup regardless, but I'm just trying to gather input right now to make sure I don't break anyone's workflow.

[andyprough]

To check glibc version, I use the command

Code: Select all

ldd --version

Mine is version 2.35

To check libstdc++ version, I use:

Code: Select all

apt search libstdcc++ | grep installed

and then look at the results - I have libstdc++6. To get the exact version number, I use

Code: Select all

apt policy libstdc++6

Mine is version 12.3.0

As far as whether or not you should move up to glibc 2.28 - I don't use old versions of any OS. With GNU/Linux, there's plenty of lightweight current distros available that work great on ancient hardware. So it's fine by me if you move forward.

[Pentium4User]

Oracle Linux is based on RHEl 7 form 2014. Oracle Linux and RHEL version 9 already exist. For most users, there is no reason not to upgrade.
The same for Debian.
8 and 9 are already out of support.
12 is released, are there still Epyrus users on 10?

[athenian200]

Oracle Linux is based on RHEl 7 form 2014. Oracle Linux and RHEL version 9 already exist. For most users, there is no reason not to upgrade.
The same for Debian.
8 and 9 are already out of support.
12 is release, are there still Epyrus users on 10?

Correct, Oracle Linux 8 is basically a rebuilt RHEL 8 with different branding.

The main reason I'm only upgrading to OL8 and not ready to move to OL9, is because OL9 ships with GCC 11 out of the box, and 11 is a lot newer than anything we've extensively tested UXP with so far. The current Pale Moon is only tested with GCC 9 on Linux. I'm pretty confident I can make GCC 10 work with Epyrus on Linux (since it works just fine on Solaris for Pale Moon builds), but I do have the option of falling back to 9 if anything goes wrong.

Probably not many of them are using Debian 8 or 9 directly, though there is an ELTS sort of thing for them that goes to 2027 for Debian 9. The main concern is that they might be using some obscure fork of Debian that is slower to update. Putting RHEL aside for a moment, most popular Linux distros are forks of Debian or Arch... some of which update a little faster, others of which update a little slower. Arch is bleeding edge, and RHEL forks are always stability-focused clones, so that mostly leaves Debian forks as the ones that could be doing enough independent stuff that it creates uncertainty. There's also the semi-independent ones, like Mageia, Gentoo, Slackware, openSUSE, and Void, but it would be impossible to account for everything at that point.

I figure it wouldn't hurt to get a rough idea of the minimum glibc version we need to support, since I believe part of why we were on CentOS 7 so long in the first place was simply that a lot of people hadn't yet updated to glibc 2.20, and I'm wondering if that's still the case or not.

[Moonchild]

The main reason I'm only upgrading to OL8 and not ready to move to OL9, is because OL9 ships with GCC 11 out of the box, and 11 is a lot newer than anything we've extensively tested UXP with so far.

I've also run into issues getting a build environment set up in OL9 because they removed a whole bunch of packages we need.

[Basilisk-Dev]

The main reason I'm only upgrading to OL8 and not ready to move to OL9, is because OL9 ships with GCC 11 out of the box, and 11 is a lot newer than anything we've extensively tested UXP with so far. The current Pale Moon is only tested with GCC 9 on Linux. I'm pretty confident I can make GCC 10 work with Epyrus on Linux (since it works just fine on Solaris for Pale Moon builds), but I do have the option of falling back to 9 if anything goes wrong.

Internally I have been running Linux builds of Basilisk built with GCC 11 and march=native instead of the standard release builds for over a year. I can't think of a single time I've experienced a crash that wouldn't have also occurred with the standard GCC 9 release build.

[distantpluto]

I build (-march=znver3) Pale Moon (AUR) on Arch Linux every time there's a new release...

pw -i glibc gcc

Code: Select all

core/glibc 2.38-7 [installed]
    GNU C Library
core/lib32-glibc 2.38-7 [installed]
    GNU C Library (32-bit)
extra/aarch64-linux-gnu-glibc 2.38-1 [installed]
    GNU C Library ARM64 target
core/gcc 13.2.1-3 [installed]
    The GNU Compiler Collection - C and C++ frontends
core/gcc-libs 13.2.1-3 [installed]
    Runtime libraries shipped by GCC
core/lib32-gcc-libs 13.2.1-3 [installed]
    32-bit runtime libraries shipped by GCC
extra/aarch64-linux-gnu-gcc 13.2.0-1 [installed]
    The GNU Compiler Collection - cross compiler for ARM64 target

[Navigator]

Using andyprough's commands.

ldd (Ubuntu GLIBC 2.35-0ubuntu3.5) 2.35

libstdc++6: Installed: 12.3.0-1ubuntu1~22.04

Merry Christmas!

[jb_wisemo]

For Linux machines I am on various Debian versions, with newer configs using Debian 12 with glibc 2.36, libstdc++ 12.2.0-14 and gcc 12 . But I am also looking at 64 bit ARM devices with this or older versions.

For Windows, I haven't decided exactly which current version to use .