Bryan Kadzban wrote:
> Matthew Burgess wrote:
>> On Fri, 21 Jan 2011 15:48:09 -0600, Bruce Dubbs <[email protected]> 
>> 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.  :-(

I don't think I agree.  If setting the --enable-kernel= option allows 
the tests to pass with the __ASSUME_ symbol__ASSUME_s set at their 
default, then there is something going on to change the behavior.

On a slightly OT note, I still get a failure on tst-cpuclock2 when 
building via jhalfs, but not when building manually. I guess I need to 
modify the jhalfs scripts to output the results before removing the 
glibc-build directory.  We do note that tst-cpuclock2 is a problem test 
in the book.  My latest test used --enable-kernel=2.6.33 and a 2.6.35.2 
kernel.

   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to