-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Jeremy Huntwork wrote: > Bryan Kadzban wrote: >> Ken Moffat wrote: >>> but also I think we should encourage >>> people to build a new kernel first (if they aren't using a Live CD) >>> so that they can be sure it works with their .config, and then they >>> can use --enable-kernel=current. >> >> Hmm. I wouldn't want to set it any higher than the minimum required on >> the host, which I believe is determined currently by the process to >> generate udev NIC names? Though the actual page only says "2.6.x", hmm. >> >> I *think* the udev process required 2.6.8 or newer to work at all, and >> 2.6.18 for some kind of enhancement (comments perhaps?). I wonder if we >> need to set it at least that high. > > Perhaps I'm not understanding your point. Certainly > --enable-kernel=current would cover that very circumstance?
My point was not very well made. It's two-fold. First, I'd rather not use =current, just because we (could) end up building a different glibc on every different kernel that way. If we pick a given version string and use it, then building on any given kernel should yield the same glibc binary. Forcing the user to build a newer kernel (of a fixed version) before starting the book would help with this, but I'll hold off on that until the end. Second, if we choose something for --enable-kernel that's newer than 2.6.0, then I don't want to set it any higher than what the host system pre-reqs page says. (Otherwise someone will start a build, get to chapter 6, and not be able to run some tool because chapter 5's glibc was built for a kernel that's too new.) And I see that the page in question simply says 2.6.x; this should be made more specific. I then remembered some kernel version requirements of the udev network-device hack (2.6.8); I suspect the minimum host kernel version is that one. Though it may be newer, I don't know for sure. So we could use 2.6.8 for --enable-kernel=, and update the prereqs page to match. Or we could leave it at 2.6.0 and update the prereqs page anyway (at least for 6.4). (That's assuming my understanding of the flag is correct. I believe that setting it to something too old will add some extra compatibility code, but setting it to something too new will cause program breakage. Using the current kernel would work, if we could assume that after a reboot, the same (or newer) kernel will be in use. I'm not willing to make that assumption, given the backward-version breakage that RH and friends have caused in the past with stuff like binutils.) Forcing the user to build the kernel before they start may work, but I'm not entirely sure I want to change things that much right now. Maybe for 7.0? (Actually it may cause grief with the installed distro's udev system, especially if the wrong CONFIG_ compatibility sysfs flags get unset...) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI/V15S5vET1Wea5wRA4QYAJwNwd/2ttSvg+4wQHy1oI6fv5pBzQCgjbfX DCQAyRD7saJGBfuRy3KSQso= =Nq91 -----END PGP SIGNATURE----- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
