11

I am staring at the output of:

% file -b /lib/x86_64-linux-gnu/*.so | grep ", for"  | colrm 1 130 | sort -u
=5018237bbf012b4094027fd0b96fc22a24496ea4, for GNU/Linux 3.2.0, not stripped
9f21d, for GNU/Linux 3.2.0, stripped
bee51, for GNU/Linux 3.2.0, stripped
, for GNU/Linux 3.2.0, stripped
sha1]=2e5abcee94f3bcbed7bba094f341070a2585a2ba, for GNU/Linux 3.2.0, stripped

What is special about GNU/Linux 3.2.0? This is on a Debian/bullseye system (amd64).

In other word: what API / functionality was introduced in GNU/Linux 3.2.0 (threading model, security functions...) that is so important ? Explicit setting of required version will prevent user from using some LD_ASSUME_KERNEL values, so I am guessing there is a good reason for rejecting old values such as LD_ASSUME_KERNEL=2.4.19 (for example).

malat
  • 2,708
  • 4
  • 27
  • 47
  • 2
    Indeed, what's so special? I see nothing special in your output. – Artem S. Tashkinov Apr 05 '22 at 12:28
  • 7
    By the way, "GNU/Linux" is an amusing hypercorrection when it's referring to just the kernel. – Kaz Apr 06 '22 at 06:40
  • 1
    @Kaz Not really? The binaries in question are linked against glibc, so they are for a GNU userspace running on a Linux kernel. If you run `file` on a binary linked against musl instead, you will not see any such reference to GNU (or Linux actually, which I find particularly interesting, but that’s beside the point). – Austin Hemmelgarn Apr 06 '22 at 11:39
  • @AustinHemmelgarn, that looks like the kernel version number, so I think it should indeed be just "Linux 3.2.0". There's no common versioning for the whole GNU/Linux stack, or for just kernel+glibc. (And to have a common versioning, you'd need to decide exactly which tools you count in it...) – ilkkachu Apr 06 '22 at 13:55
  • @AustinHemmelgarn While that is correct, the number is expressing what version of the Linux kernel is expected by the library. 3.2.0 is a version of Linux, not of GNU/Linux. There is no program by the name of GNU/Linux, let alone one that has a concrete version number. It's a type of distribution. If there is another word in front of it like Debian, then it makes sense with a version number: Debian GNU/Linux 11. – Kaz Apr 07 '22 at 00:37
  • Technically, “for GNU/Linux 3.2.0” reflects the `EI_OSABI` and `EI_ABIVERSION` fields in [the ELF identification header](http://www.sco.com/developers/gabi/latest/ch4.eheader.html#elfid). These indicate that the binary uses ELF extensions, in this case `ELFOSABI_GNU` (aka `ELFOSABI_LINUX`) with version 3.2.0. This only has meaning when used for glibc, and glibc chooses to use a version based on the kernel version as its ABI. So “Linux 3.2.0” would be misleading; it’s really “glibc on Linux 3.2.0”. – Stephen Kitt Apr 08 '22 at 10:42

1 Answers1

26

In the past, the GNU C library had its minimum kernel version periodically bumped, which typically allowed for a number of simplifications. The C library contains lots of code to handle variations between kernel versions, for example new system calls used preferentially when possible. Raising the minimum kernel version means that the code handling older variations can be dropped.

3.2.0 is only significant in that it’s the last kernel version for which the GNU C library went through this process. It was initiated by Joseph Myers in January 2016, when 2.6.32 (the previous minimum kernel version) reached its end of life. 3.2 was the then-current oldest supported kernel.

The bump itself was implemented in two commits, first for all non-x86 architectures in February 2016, and then for x86 architectures in May 2017. (The delay was related to OpenVZ support concerns.) There were many other follow-up patches to remove no-longer-necessary code or simplify code, for example this simplification of recvmmsg.

This doesn’t mean that the GNU C library doesn’t support features added to the Linux kernel since 3.2.0; it does, in a variety of ways. Some features are supported as improvements (e.g. clone3), others are simply made available (e.g. close_range), others are made available with compatibility fallbacks (i.e. the work done by the new system call is done by the library if the system call isn’t available).

You can also build the C library with a requirement for a given kernel version, with the --enable-kernel configuration option.

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • Right, all my (file *.so | grep ...) are coming from libc6 package. This [post](https://unix.stackexchange.com/a/430462/32896) also confirms your explanation. Thanks ! – malat Apr 05 '22 at 12:57
  • 2
    Can you explain how the development process changed? In particular, why is the 3.2.0 kernel the last version for which the C library got a minimum kernel version bump? Or is it just the latest version and the process will continue some time in the future? – JohnEye Apr 06 '22 at 09:25
  • 3
    @JohnEye There will probably be another bump to the minimum supported kernel version _eventually_. It's just a question of when the pile of backward compatibility code builds up to the point where it's felt to be worthwhile to chop off the trailing edge of Linux distributions again. – zwol Apr 06 '22 at 20:09