bug#30537: glibc 2.26 refuses to run on CentOS 6.8

[Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>]

Leo Famulari <leo@famulari.name> writes:

> On Mon, Feb 19, 2018 at 08:22:29PM -0500, Leo Famulari wrote:
>> My questions are, how does the glibc team choose the minimum kernel
>> version? What could go wrong if we apply this patch and somebody uses
>> Guix on a pre-3.2.0 kernel?
>>
>> Perhaps they simply chose to not support glibc on any kernel that is not
>> supported upstream; 3.2.x is the oldest supported release series. But,
>> we should have some idea of their reasoning, in my opinion.
>
> As far as I can tell, the discussion started on the libc-alpha mailing
> list in January 2016:
>
> https://sourceware.org/ml/libc-alpha/2016-01/msg00885.html
>
> ... and continued into February:
>
> https://sourceware.org/ml/libc-alpha/2016-02/msg00002.html
>
> These messages can provide some useful context.

The only reason for moving the lower bound to Linux 3.2 is that 2.6 has
reached EOL.  This allows the glibc developers to assume certain
kernel features and simplify their code.

The RHEL kernels are special, though, in that they are continuously
patched beyond recognition, backporting features.  A RHEL 2.6.32 kernel
is very different from a stock 2.6.32 kernel.

The patch explicitly permits a *single* extra kernel version (0x020620 =
2.6.32) at runtime, not *all* older kernels, so it isn’t as bad as it
may seem.

For future updates to the glibc we would have to re-evaluate if the
current RHEL 6.x kernel still supports all features the glibc expects,
and decide once more if we can justify patching glibc to allow that one
particular kernel version.

--
Ricardo