glibc issues with --enable-kernel=22.214.171.124
matthew at linuxfromscratch.org
Fri Jan 21 11:38:03 PST 2011
On Fri, 21 Jan 2011 12:13:21 -0600, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
> Matthew Burgess wrote:
>> On Fri, 21 Jan 2011 11:32:34 -0600, Bruce Dubbs <bruce.dubbs at gmail.com>
>>> In any case, should we change the book to update the glibc kernel
>>> to 2.6.30? I don't know if a similar change to the host system
>>> prerequisites is also needed or not.
>> I think we'd be wise to update the host system prerequisites. My
>> is that the --enable-kernel= will cause Glibc to omit fallbacks for
>> older than that. That could mean that any programs we build against
> that Glibc
>> will fail if the host system isn't at the specified version of the
> kernel or
>> newer. At the very least, we'd have to state that the tests depend on
>> version of the host system's kernel.
> 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 126.96.36.199 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
188.8.131.52 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.
More information about the lfs-dev