Ready to bump glibc to 2.12? ({i686,x86_64}-unknown-linux-gnu)

tools and infrastructure
1

Continuing the discussion from Bumping glibc requirements for the Rust toolchain:

Over 2 years ago, in the thread above, we were considering updating the Rust distribution builders from a CentOS 5 image to a CentOS 6 image. With the way glibc symbol versioning works, this would raise the minimum system level that can use the resulting binaries. This would only affect i686-unknown-linux-gnu and x86_64-unknown-linux-gnu; other linux-gnu architectures already use newer baselines.

From my position at Red Hat, I'll point to the life-cycle dates -- note that RHEL 5 was retired on March 31, 2017. It continues now in extended support, only fixing critical security issues and the most urgent bugs. CentOS 5 followed suit and is now only available in the archives, with no updates at all.

Last time this came up, @petrochenkov reported using SLES 11 with glibc 2.11. Do you still need this? From SUSE's lifecycle page, it looks like SLES 11 ended general support on March 31, 2019.

Does anyone else have concerns about raising to a ~RHEL/CentOS 6 equivalent of glibc 2.12?

cc @alexcrichton -- we talked about this a little at RustConf.

PS: Due to build requirements explained here, I would still like RHEL 5 kernel support for now.

1 Like
2

I no longer need this personally.

3

Without bumping the kernel requirement I don't think that this will have many source-level changes in libstd, right? Otherwise I think this would largely just lead to a simplification of the build containers for i686/x86_64 release on Linux?

(or are there other fallout improvements I'm missing?)

4

Mostly this. I think we have a few compatibility hacks on the LLVM source too.

5

I'm testing the docker updates. Two new symbols so far are pthread_getname_np@GLIBC_2.12 and pthread_setname_np@GLIBC_2.12. LLVM detects and uses both, and jemalloc also uses the latter. We could also start using that in std (although I don't know about android):

6

Hmm, a harder one is futimens@GLIBC_2.6 in LLVM, calling the utimensat syscall in 2.6.22.

Then jemalloc also calls sched_getcpu@GLIBC_2.6, calling getcpu in 2.6.19.

So I guess it's not a good idea to try this until I'm ready to move the kernel version too.

7

I'm not familiar with the configuration process for LLVM or jemalloc, but it might be possible to tell it not to use the troublesome symbols with whatever the equivalent of an Autoconf config.site file is. (With Autoconf, for instance, you could put ac_cv_func_futimens=no in the config.site file and that would force the configure script to consider futimens unavailable.)

8

Interesting, I haven't used config.site before -- maybe that could work for jemalloc.

LLVM uses cmake check_symbol_exists, and I'm not sure if command line -D flags can override that.

However, if I have to play whack-a-mole with these symbols, that burden seems worse than the status quo. We might as well stick with the CentOS 5 base for a while longer.

9

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.