glibc issues with --enable-kernel=220.127.116.11
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 18.104.22.168 (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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 261 bytes
Desc: OpenPGP digital signature
More information about the lfs-dev