On Fri, 21 Jan 2011 20:52:56 -0800, Bryan Kadzban <br...@kadzban.is-a-geek.net> wrote: > Matthew Burgess wrote: >> On Fri, 21 Jan 2011 15:48:09 -0600, Bruce Dubbs <bruce.du...@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.
Ah, thanks for the correction. So while the build won't be the same byte-for-byte (as you say, compat code will be included/omitted dependent on the --enable-kernel value), it will be the same feature-wise. If a reader decides to build using an old host kernel, they may get ENOSYS/EINVAL with certain Glibc calls, but once they've rebooted into the LFS system those same calls will then work. > 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. :-( Whilst I don't want to drag this discussion on for too long, I'm not sure I follow this though. I'm sure some of the Glibc failures could be due to the fact that those tests are testing for features that the host's kernel simply doesn't support, so instead of the expected output/return value, they'll be returning ENOSYS/EINVAL. Thanks, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
