glibc-2.10.1 make check fails

Bryan Kadzban bryan at kadzban.is-a-geek.net
Tue May 26 23:48:02 PDT 2009


Dan Nicholson wrote:
> On Tue, May 26, 2009 at 12:40 PM, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
>> Dan Nicholson wrote:
>>> On Tue, May 26, 2009 at 9:32 AM, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
>>>> Using 2.6.18 appears to potentially affect binaries built
>>>> against kernels older than that and run on a LFS-6.5 or later
>>>> system. I don't see where that would be an issue.
>>> I don't think it affects binaries. It only affects what kernel
>>> you're running. You can have an ancient binary, and so long as
>>> the binary format and interfaces are still supported on the
>>> system you're running, it should be fine.
>> It sounds like you are agreeing with me.  An ancient binary will
>> not run if the support is not built into glibc.
> 
> But I think we're disagreeing on what "the support" is. A binary 
> compiled on LFS-6.0 will be ELF, which is the same. Likewise, glibc 
> and the kernel provide excellent backwards compatibility in
> interfaces (regardless of what --enable-kernel setting was used for
> the LFS-6.0 glibc). So, there's a near 100% chance that an LFS-6.0
> binary will run on LFS-6.5, and the --enable-kernel setting has no
> bearing on that.

--enable-kernel *ONLY* affects two things (at least in my experience):

1: The minimum kernel that glibc ensures is running every time a program
starts up (note when running a program under strace, something in the
program makes a _sysctl syscall, asking for CTL_KERN / KERN_VERSION)

2: The amount of extra compatibility code included in glibc to handle
various different kernel versions

The second item here is the reason for the first item: since glibc has
removed compatibility code for the older kernels, it refuses to run on
those kernels.

To be clear: This has nothing to do with what system a *program* was
compiled on (unless it statically linked glibc), and everything to do
with simply enforcing a match between the running glibc and the running
kernel.

(One instance of "removing compatibility code" would be pselect / ppoll:
those actual syscalls never existed until 2.6.16.  Before that, they
were emulated in glibc, but the race condition that they were added to
the standard to prevent was still possible.  If you set --enable-kernel
to 2.6.0, then you get the emulation code still compiled into glibc, and
used if the kernel says the pselect syscall doesn't exist -- but if the
pselect syscall *does* exist, glibc will use it.  The only thing that
--enable-kernel=2.6.16 (or later) gives you here is the removal of that
emulation code, which just creates a slightly smaller glibc, and stops
it from working properly pre-2.6.16.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20090526/73b3099d/attachment.sig>


More information about the lfs-dev mailing list