glibc issues with --enable-kernel=

Ken Moffat ken at
Fri Jan 21 15:24:01 PST 2011

On Fri, Jan 21, 2011 at 03:27:57PM -0700, Matthew Burgess wrote:
> If we set it to 2.6.30 (there's no point in adding the stable version as
> Glibc only checks the major.minor.patch level), we'll miss out on
> F_GETOWN_EX (new in 2.6.32 - see and
> recvmmsg (new in 2.6.33 - see support.
> Release dates of those kernels are as follows:
> 2.6.30 - 10-Jun-2009
> 2.6.32 - 03-Dec-2009
> 2.6.33 - 24-Feb-2010
> So, by the time LFS-6.8 is released, 2.6.33 will have been out for just over
> 12 months.  Given that most major distros have moved to a 6-month release
> cycle, and that LFS-6.7 also meets that dependency, I don't think it's an
> overly hard-to-meet requirement, so I propose bumping it straight up to
> 2.6.33.
> Thoughts?
> Matt.
 Sounds good.  For my own builds, I normally run a host kernel newer
than glibc knows about.  I specify --enable-kernel=2.6.33 at the
moment.  I prefer it to =current because it reminds me to check what
versions glibc knows about when I build a new system. [ I usually
build several new kernels each month, most of them -rc versions ].

 Very rarely, e.g. when I was first messing with kms, I might
specify a slightly older kernel if I think I might have to bisect
kernel problems.

 But then, I'm usually a firm believer in "run the kernel (on the
host) that you intend to use on the new system".  Saves aggravation
trying to sort out an old .config that broke across kernel upgrades -
it's much easier to fix those problems in a full-featured system.

 I can see that isn't possible for people using a Live CD, but for
everyone else I still recommend it.

das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-dev mailing list