glibc issues with --enable-kernel=2.6.22.5

Bruce Dubbs bruce.dubbs at gmail.com
Fri Jan 21 14:34:20 PST 2011


hauradou wrote:
> Bruce Dubbs a écrit :
>> Matthew Burgess wrote:
>>
>>   
>>>> I'm not sure about that.  We are not building glibc against the host
>>>> kernel.  We are using the most recent headers from section 6.7.  By
>>>> specifying --enable-kernel= we are only telling the build system what
>>>> features to use.
>>>>       
>>> Yes, I understand that.  However, when it comes to running the tests in
>>> chapter 6, we haven't yet rebooted into the LFS kernel yet.  Therefore,
>>> the test results will obviously depend on whether or not the features
>>> they are testing for are available in the host kernel or not.
>>>
>>> For example, assume the host has a 2.6.22.5 kernel (our current earliest
>>> supported version).  If we then specify --enable-kernel=2.6.30 to the
>>> chapter 6 Glibc build, that Glibc may contain features that are only
>>> available in 2.6.30 kernels and provides no fallbacks for the
>>> 2.6.22.5 version.  At that point, running the tests or even trying to
>>> run any of the binaries linked against that version of Glibc could fail
>>> if they happen to touch those bits of Glibc that only support Linux >=
>>> 2.6.30.  So, basically, if we bump the --enable-kernel parameter, we
>>> also need to bump the host system requirements.
>>>     
>> 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).
>>
>>    -- Bruce
>>
>>
>>   
> what about changing that glibc configure line into something like:
> enable-kernel=`uname -r | awk -F. '{ print $1"."$2"."$3 }'`
> So that any of these versions could be convenient ?

That's not a bad idea, but if the user's host kernel is too old, then we 
get failures in the glibc tests.  It's nice to have a clean test.  I'm 
not sure if the test failures are a real problem though.  Of course it 
depends on what functionality fails.

   -- Bruce



More information about the lfs-dev mailing list