Dan Nicholson wrote: > On Tue, May 26, 2009 at 12:40 PM, Bruce Dubbs <bruce.du...@gmail.com> wrote: >> Dan Nicholson wrote: >>> On Tue, May 26, 2009 at 9:32 AM, Bruce Dubbs <bruce.du...@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.)
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
