On Tue, May 26, 2009 at 9:32 AM, Bruce Dubbs <bruce.du...@gmail.com> wrote: > Dan Nicholson wrote: >> On Sun, May 24, 2009 at 10:51 PM, Bryan Kadzban >> <br...@kadzban.is-a-geek.net> wrote: >>> Bruce Dubbs wrote: >>>> --enable-kernel=VERSION compile for compatibility with kernel not older >>>> than >>>> VERSION >>> 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://www.mail-archive.com/arch-dev-pub...@archlinux.org/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: >>> >>> http://repos.archlinux.org/viewvc.cgi/glibc/repos/core-x86_64/PKGBUILD?r1=36985&r2=39100 >>> >>> 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: >> >> http://cvs.fedoraproject.org/viewvc/rpms/glibc/devel/glibc.spec?view=diff&r1=1.376&r2=1.377 >> >> 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 regardless. 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. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
