Brew: Update glibc and gcc

[sjackman]

glibc 2.26 https://github.com/bminor/glibc/releases/tag/glibc-2.26

On most architectures, GCC 4.9 or later is required to build the GNU C Library.

Linux kernel 3.2 or later is required at runtime, on all architectures
supported by that kernel. (This is a change from version 2.25 only for
x86-32 and x86-64.)

glibc 2.25 https://github.com/bminor/glibc/releases/tag/glibc-2.25

glibc 2.24 https://github.com/bminor/glibc/releases/tag/glibc-2.24

The minimum Linux kernel version that this version of the GNU C Library
can be used with is 3.2, except on i[4567]86 and x86_64, where Linux
kernel version 2.6.32 or later suffices (on architectures that already
required kernel versions more recent than 3.2, those requirements remain
unchanged). Linux 3.2 or later kernel headers are required on all
architectures.

glibc 2.23 glibc 2.24 https://github.com/bminor/glibc/releases/tag/glibc-2.23

The minimum GCC version that can be used to build this version of the GNU
C Library is GCC 4.7. Older GCC versions, and non-GNU compilers, can
still be used to compile programs using the GNU C Library.

[sjackman]

I'd like to add default kernel versions to this table of common Linux distributions.
https://github.com/Linuxbrew/brew/wiki/Bottles#glibc-version

[sjackman]

glibc 2.26 has a minimum kernel version of 3.2. glibc 2.23 through glibc 2.25 had a minimum kernel version of 2.6.32. Increasing the minimum kernel version would remove bottle support for some older distributions of Linux.

[sjackman]

@iMichka @maxim-belkin @xu-cheng @jonchang @tseemann Thoughts?

[jonchang]

Mm, so this would drop bottle support for RHEL/CentOS 6 and Ubuntu Precise 12.04? Precise is out of support but CentOS 6 is supported for 2 more years. I believe Linuxbrew uses glibc 2.23; is the motivation to move to 2.26 instead of say 2.25 because GCC 4.7 is a pain to use?

[sjackman]

We currently build our bottles on Ubuntu 16.04 LTS (Xenial Xerus) with glibc 2.23 and gcc 5.4.0. Ubuntu 18.04 LTS (Bionic Beaver) will be released at the end of this month. We'd like to eventually switch to it for our bottling. The primary reason would be to switch from GCC 5.4.0 to GCC 7.3.0.

Perhaps we should put off switching for a while longer.

[xu-cheng]

I would wait till CentOS 6 reaches EOL, which is supposed to be 30 November 2020. In comparison, Ubuntu 16.04 TLS will reach EOL at April 2021. Further, I don't think there is any advantage to upgrade glibc currently for Linuxbrew users in general.

[sjackman]

I agree there is probably little advantage to upgrading glibc. There may be an advantage to upgrading gcc to GCC 7. The easiest way to do that is to update our bottling Docker image from Ubuntu 16.04 to Ubuntu 18.04. That upgrades GCC 5 to 7, but also upgrades glibc from 2.23 to 2.26.

Debian 9 provides glibc 2.24 and GCC 6.3.0. If we found a need to upgrade from GCC 5 to GCC 6, that could be an option that doesn't require a newer Linux kernel version.

I suggest that we postpone upgrading the bottling architecture until we find a real and pressing need to update the compiler from GCC 5 to GCC 6 or 7.

[iMichka]

Homebrew’s goal is to always have the latest packages. They also support only the last 3 Mac OS versions (officially).

Linuxbrew’s goal should be sort of the same.

It is just a coincidence that Linuxbrew was mostly maintained by science people, which have OS upgrade cycles of more than 10 years. So Linuxbrew tries hard to support old linuxses (which sort of works).

I would like to see the effort of maintaining old kernels and linuxeses in a separate fork. A little bit like Tigerbrew worked for that old version of Mac OS. Of course this splits a little bit the effort on a second team.

One of the reasons is that I would like to have the Gcc formula point to the latest gcc version, like on Mac.

The Linux ecosystem is really cluttered. Most of the support questions I get here are for CentOS. I would like an official list of Linux versions we do support.

Personally I would like to move to Ubuntu 18.04 as soon as possible. We can have a grace period of 2-3 month, until Ubuntu 18.04 has stabilized.

But I could live with Ubuntu 16.04 until it is EOL. Maybe we could move to gcc 6 as a first step, which allows to see if everything compiled correctly (and I bet a lot of stuff will be broken).

[xu-cheng]

It is just a coincidence that Linuxbrew was mostly maintained by science people, which have OS upgrade cycles of more than 10 years.

FWIW, that is one of the main reasons to use Linuxbrew. Personally, I would use system package manager (apt-get, yum, dnf, etc) on Linux machines I have total control. But for science community, it is usual that users do not have the root access in High Performance Computing system or clusters from the university. We also have little control over OS upgrading schedule. In such case, Linuxbrew becomes one of very few choices.

Homebrew’s goal is to always have the latest packages. They also support only the last 3 Mac OS versions (officially).

On the one hand, I would argue that Apple and Linux in general have quite different philosophies on supporting and maintaining the old systems. You could say Apple effectively only supports the latest OS. So we should not apply Homebrew's policy on OS version directly on Linuxbrew. On the other hand, I don't think supporting old OS kernel somehow invalids the goal of offering the latest packages in general. For example, we do offer gcc@7 for the users who need it.

[maxim-belkin]

I agree with @xu-cheng. I see Linuxbrew users as those who can't use apt-get, yum, etc. Ideally, Linuxbrew would support several major OSes. What is missing is workforce (contributors). It could be in part because Linuxbrew is following the path of Homebrew in trying to support only "the latest and the greatest". I don't think "analytics" can tell us something useful in this case because if users are having trouble installing Linuxbrew on their OSes, we won't see them in analytics.

Having said that, I don't see Linuxbrew as a solution for HPC systems at the moment because they represent a very special case of Linux system with their additional complications. So, I think at this very moment it is totally reasonable to try and follow the path of Homebrew without dropping the support for old systems completely.

[sjackman]

Increasing the minimum kernel version requirement of Linuxbrew is a big deal, because it's the one component of the system that absolutely cannot be updated by the user without admin privileges. Everything else (glibc, gcc, et c) we have control over.

Although the glibc and gcc version are somewhat coupled, but not inextricably so. We could update the gcc version used to bottle without also updating glibc. It's just easier to do both at once by updating the version of Ubuntu on which we bottle.

Bumping the default gcc version would arguably create more trouble than it would solve. We start getting build failures on formulae that fail to build with GCC 7, and there are few formula that fail to build with GCC 5 but do build with GCC 7. For those formulae we have the option of using the new gcc@7 formulae. (Thanks, @xu-cheng!)

Currently gcc@7 is the default compiler on systems that have it installed. See PR https://github.com/Linuxbrew/brew/pull/676. I'm curious to see whether gcc@7 as the default compiler on a user's system can interoperate relatively trouble-free with bottles built by GCC 5.

I suggest we revisit this issue once Ubuntu 18.04 has overtaken Ubuntu 16.04 as the most popular Linuxbrew distribution on the Analytics. This would be biased by the users using the linuxbrew/linuxbrew Docker image, which is currently based on Ubuntu 16.04. We can create an official linuxbrew/ubuntu Docker image that is based on the most current LTS version of Ubuntu, once Ubuntu 18.04 LTS (Bionic Beaver) is released.

[xu-cheng]

I'm curious to see whether gcc@7 as the default compiler on a user's system can interoperate relatively trouble-free with bottles built by GCC 5.

No, it would not work. Because I deliberately make gcc and gcc@* use different libraries path/rpath to allow them coexist in the same system. Therefore, a bottle built by gcc 5 cannot be run in a system with only gcc@7 installed.

But it we choose to bump the main gcc formula to gcc 7, I think all old bottles built by gcc 5 can indeed be run by the new system, since it is designed to keep backward compatiblity.

[sjackman]

Therefore, a bottle built by gcc 5 cannot be run in a system with only gcc@7 installed.

I'd expect that it can run on a system with both gcc and gcc@7 installed.

But it we choose to bump the main gcc formula to gcc 7, I think all old bottles built by gcc 5 can indeed be run by the new system, since it is designed to keep backward compatibility.

That's what I'm hoping.

[tseemann]

My needs are different. Our mini-cluster uses RHEL 7 (aka Centos 7) and a shared /home filesystem over NFS. Linuxbrew has enabled us to have a common software stack across all nodes, which is cutting edge on everything, as research environment needs that. We use singularity for the "production stuff".

I fear a big change if it is not necessary yet. We're only partway through brew-sci and it takes a lot of time, so I don't want to add to that burden.

[iMichka]

I am fine to wait a little bit with the update. There is no need for the moment. We can wait until the EOL of CentOS or Ubuntu 16.04. Of course that decision can be reverted if we feel that a faster change is needed.

Maybe we should have a mini roadmap + table of glibc/gcc/kernel, and write down th decision we have taken here. We should be as transparent as possible regarding that matter for our users (and more importantly for the maintainers).

[sjackman]

Once we've decided to upgrade glibc and/or gcc we can announce it through our usual channels (Linuxbrew Updates and Twitter). The decision for now is that there is no imminent update of glibc or gcc planned.

[jhdub23]

Agree with xu-cheng. The primary reason our group is considering using linuxbrew is to be able to use newer tools on old systems, where we have no control over the kernel or system tools/libraries. If we had control over our systems, we would ditch linuxbrew and just use yum.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[iMichka]

Just closing here. Ubuntu 18.04 is out now. I think the wish it to wait a little bit before migrating to gcc7 and a newer glibc. Not sure we will wait until the EOL of Centos 6 or Ubuntu 16.04, but who knows :)