libcxx presubmit should be tested against minimal supported glibc (2.24)

[zeroomega]

In https://libcxx.llvm.org/#platform-and-compiler-support, it mentioned the minimal supported glibc on Linux is glibc-2.24, which is from Debian 9 Stretch. However, all libcxx presubmit builders uses a docker image from Ubuntu 20.04, which has glibc-2.35, see:

➜  ~ docker run -it --entrypoint bash 'ghcr.io/llvm/libcxx-linux-builder:b9a2658a3e8bd13b0f9e7a8a440832a95b377216'
runner@0b34c8fcc3c5:~$ /usr/lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Ubuntu GLIBC 2.35-0ubuntu3.8) stable release version 2.35.
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 11.4.0.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
<https://bugs.launchpad.net/ubuntu/+source/glibc/+bugs>.

This could potentially cause issues as non of the presubmit builder could catch a change that breaks glibc 2.24. We should explicitly use the minimal supported glibc on part of, if not all of libcxx presbumit builders for linux.

FYI, Ubuntu 18.04 LTS Bionic has glibc 2.27. Ubuntu 16.04 LTS Xenial has glibc 2.23.

[ldionne]

IIRC, the version of glibc we support was decided based on the OSes we supported in pre-commit CI at the time. I think the documentation was likely not kept up-to-date as we were making CI upgrades, leading to the current situation.

I'd be curious to see what breaks if we try downgrading the version of Ubuntu in our CI -- I'm not entirely closed to the idea but I don't think that would be a net benefit for the project, instead we should likely push to move things forward. Glibc 2.24 is about 9 years old at this point so it's probably time for us to consider moving forward.

[zeroomega]

@ldionne
I raise this is due to the recent discussion started from PR#119025 and PR#120946. And my objective is of course to to make libcxx presubmit builders better so they can catch such breaking change before it started affecting downstream builders from different orgs. We would like to improve the libcxx presubmit test coverage and I am already testing some different configurations and I would like to start working on setting up presubmit builders once some of my local experiments get mature enough. This bug ticket is part of effort to identify what are missing in the current libcxx presubmit builders. I am not a libcxx contributor or expert on this, so if I said something wrong, please correct me.

Our team actually don't have an obligation to support a certain version of glibc, we produces toolchain packages that is capable to target linux, mac, windows, baremetal armv7/riscv and fuchsia. We also have a fleet of bots that runs on a relatively new Ubuntu 22.04 (instead of 20.04 from libcxx docker image). The toolchain we produces is used by multiple teams in Google, and some developers outside of Google as well, not just by Fuchsia develoeprs. We always build our toolchain in a hermetic way, that all the dependency, including the host compiler, cmake, ninja, and the sysroot that coming from glibc, are version controlled instead of coming from the host machine. In this way, we won't ran into issues when we decided to update our infra fleet to a new linux distro.

We build our sysroot from Ubuntu 14.04 and we are in the process of upgrading it to 16.04, and mostly due to the reason that it is still under extended security maintenance from Canonical. There are users out there still using this version. Usually not because they don't want to upgrade, but they because they don't have luxury to upgrade, as some of their dependencies can only work on such old distro. This is extremely common in the embedded world. As a hobbyist on this, I actually need to keep a Ubuntu 18.04 VM on my personal workstation, because some SoC's SDK just won't work if I bump the distro to a newer version. If we bump the minimal required glibc, that means that the clang built from it can no longer run on these systems. For teams that have such restriction across the world, this will be a big issue.

I am not saying we should not bump the minimal supported glibc version, I think we should have a better policy when making such decision, as a decision like this could have a very large blast range. A lot of LLVM consumers are branching from the release branch, so a glibc breaking change could go in unnoticed by them and it will break the world when LLVM has a new release. We just happened to be a team that always build and test libcxx against the ToT clang and that is why we see issues frequently and complaint a lot. IMO, a glibc version bump should be treated conservatively and proposed as an RFC and discussed with a broader audience, considering how impactful it could be. And we should always test libcxx in presubmit against the minimal supported platform (not just glibc) to make sure changes not break the promise.

And FYI, the change PR#119025 will very likely break on glibc 2.24. I wasn't aware of the libcxx glibc requirement when I was debugging that, but I tested the change on Ubuntu 16.04, which was on glibc 2.23 and it failed. If you prefer, we can help to test that change on glibc 2.24 to verify it.