glibc-2.10.1 make check fails
dbn.lists at gmail.com
Tue May 26 12:19:04 PDT 2009
On Tue, May 26, 2009 at 9:32 AM, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
> Dan Nicholson wrote:
>> On Sun, May 24, 2009 at 10:51 PM, Bryan Kadzban
>> <bryan at kadzban.is-a-geek.net> wrote:
>>> Bruce Dubbs wrote:
>>>> --enable-kernel=VERSION compile for compatibility with kernel not older than
>>> Yes: abort any program at startup if the current kernel version is less
>>> than VERSION, and also remove any workarounds included in the glibc
>>> sources for kernels older than VERSION (if any).
>>>> but I found http://email@example.com/msg08016.html
>>>> which says: The minimum kernel version required for glibc was bumped from
>>>> 2.6.16 to 2.6.18
>>> That's an Arch decision (made by their maintainer), not something that
>>> applies to glibc itself. :-) See:
>>> for the actual change in their PKGBUILD script. (The section labeled
>>> "line 62".)
>> A more authoritative measure here would be to follow fedora since they
>> are the glibc maintainers. Unfortunately, there's no real rationale,
>> but their version is 2.6.18 made with this change:
>> Probably would be best to investigate why that is before making a
>> change like that.
> The reason I saw was so code didn't have to check for certain features at run
> time. The would be to make things easier for the programmers. 2.6.18
> corresponds to RHEL 5 and is a compromise for backward compatibility and
> convenience. 2.6.18 was September 2006.
This doesn't correspond to runtime checks that programmers do. It
refers to runtime checks done in glibc to enable compat paths when
necessary. By saying what your minimum kernel is x.y.z, then the
compat paths for kernel versions earlier than that will not be
compiled into libc. Glibc provides the same interfaces to programmers
If a programmer is trying to use a specific kernel feature (like
inotify), then they have to handle that in their code. Glibc's
--enable-kernel setting has no bearing on that.
> 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.
More information about the lfs-dev