guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 01/01: gnu: vlc: Update to 2.2.0


From: Mark H Weaver
Subject: Re: 01/01: gnu: vlc: Update to 2.2.0
Date: Sun, 15 Mar 2015 12:30:15 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> "Jason Self" <address@hidden> skribis:
>
>> Anyway, Debian seems sufficently slow moving to me and so I looked at
>> that to get an idea of what might be acceptable. They have 3.5 in
>> Wheezy and are jumping to 3.16 for Jessie which I understand is due
>> soon? Given that, what about using 3.14? It is much newer and
>> supported until August 2016 [0].
>
> The real problem is that our libc must be able to work kernels typically
> found out there in the wild, which may be older than this.  Thus, 3.14
> may be a bit too recent.

Note that currently, we configure GNU libc with --enable-kernel=2.6.32
with headers from linux-libre-3.3.8.  If it's incorrect to use headers
from a kernel newer than the oldest kernel we wish to support, then
we're already doing it wrong.

> Now, I think libc’s --enable-kernel can specify a baseline older than
> the available kernel headers.  So it may be that we can use 3.14 headers
> but build a libc that assumes a kernel possibly as old as 3.4.

One data point: we're running Guix and also Nginx compiled with Guix on
Hydra which runs a 2.6.x kernel, and it seems to work.

Another data point: [GNU/]Linux From Scratch uses headers from Linux
3.19 and configures GNU libc with --enable-kernel=2.6.32.  As I recall
they've been doing this for years, always using headers from the most
recent kernel but configuring libc to support older kernels.

and another: Debian currently builds their libc against headers from
Linux 3.12.6 and with --enable-kernel=2.6.32.

In summary, I think using headers from 3.14 would be fine.

      Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]