glibc issues with --enable-kernel=2.6.22.5

Bryan Kadzban bryan at kadzban.is-a-geek.net
Fri Jan 21 20:52:56 PST 2011


Matthew Burgess wrote:
> On Fri, 21 Jan 2011 15:48:09 -0600, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
>  
>> OK, so do we use 2.6.30.2 (LFS-6.5)?  Do we need to update any other
>> packages in the requirements or make everything from LFS-6.5 (Aug 2009)?
>>   Right now, the minimum requirements are from LFS-6.3 (Aug 2007).
> 
> 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 http://lwn.net/Articles/354842/) and
> recvmmsg (new in 2.6.33 - see http://lwn.net/Articles/334854/) support.

We won't actually miss out on either of those, because that's not what
--enable-kernel= changes.  It only removes compatibility code for older
kernels; it does *not* cause glibc to omit support for newer syscalls or
newer flags (assuming they're in the headers it was built against, and
assuming it knows about them at all).  If a program is running against
such a glibc on a too-old kernel (that doesn't support those syscalls or
flags), it will generally get ENOSYS or EINVAL errors.

So I don't see a need, feature-wise, to raise the minimum kernel version
at all.  :-)

Except for the glibc failures -- but it seems to me that these are
likely due to a bug in glibc.  When the two __ASSUME_BLAHBLAH symbols
are defined to different values, I think it's generating incorrect code.
 But I haven't been able to reproduce it, or strace the test file, or
gdb the test file, so I can't tell what the bug is yet.  :-(

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20110121/8ca36bb1/attachment.sig>


More information about the lfs-dev mailing list