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).

  • 2
    Indeed, what's so special? I see nothing special in your output. Apr 5, 2022 at 12:28
  • 7
    By the way, "GNU/Linux" is an amusing hypercorrection when it's referring to just the kernel.
    – Kaz
    Apr 6, 2022 at 6: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). Apr 6, 2022 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 6, 2022 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 7, 2022 at 0:37

1 Answer 1


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.

  • Right, all my (file *.so | grep ...) are coming from libc6 package. This post also confirms your explanation. Thanks !
    – malat
    Apr 5, 2022 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 6, 2022 at 9: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 6, 2022 at 20:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .