Thank you everyone for your inputs. Good point Armin. I wasn't thinking about chroot. > > -- Bruce > > Oops. I wasn't thinking about chroot too. I currently have two images, LFS 6.6 and LFS 7.3 (more like the SVN version). I got confused there, since technically, LFS 6.6 meets 7.3's HSR. I tried upgrading to kmod 13 in my 6.6 (and not 7.3) image and it failed as expected, with only GCC 4.4. My bad. Of course, it should work in 7.3/4 with GCC 4.8 installed. However, it's nice to know that kmod 14 and up doesn't build with GCC < 4.6. Thank you for pointing it out.
It actually depends on what you're trying to do. :-) > > See sysdeps/unix/sysv/linux/kernel-features.h in the glibc source tree > for the full list, but for example, accept4() got added in 2.6.28. > (Which adds flags to the syscall so that you can set O_NONBLOCK or > O_CLOEXEC on the socket that accept() returns, without racing.) So > --enable-kernel=2.6.25 would build compatibility code for when that > version doesn't exist (probably exposing the race, but not returning an > error at least), but 2.6.34 would not (it would probably yield ENOSYS). > > But getcpu(), whatever that actually does, showed up in 3.1, so either > of these --enable-kernel values would build in the compat support for > kernels where it doesn't exist. > > > The requirement for 2.6.25 is a runtime and buildtime one; udev > > requires some features only present since 2.6.25. The 2.6.34 > > requirement is a build-time one, such that Glibc doesn't include > > fallbacks for features present in that version of the kernel (I think > > I've got that right, but I think I got taken to task by Bryan last > > time this discussion came up for not getting it right!). > > That's pretty close. The configure flag definitely removes fallbacks > for missing features. > > But it's a little complicated, because if you try to exec() a binary > that links to a libc that was configured with --enable-kernel=<newer > than the current kernel>, then I'm pretty sure that libc aborts. > (Because the workarounds are not present.) So if the host is running > 2.6.28 or something, then entering the chroot probably isn't going to > work when chapter 5's libc was built with --enable-kernel=2.6.34. > > Which I think does mean that the host requirements are now 2.6.34, > actually. Unfortunately I don't have a pre-2.6.34 kernel to test with, > so I'm not 100% sure. (Testing would be building a chapter 5 and seeing > if chroot works, or if env errors out on you.) > > I do, but to be safe, I just upgraded my host's (LFS 6.6) kernel to 2.6.34. > The first error will be in ch5 during gcc pass2 and configure log will > report "Fatal. Kernel too old" because anything linking to the ch5 glibc > without compatible syscalls will die. > > >From the gnu libc installation docs: > > `--enable-kernel=version' > This option is currently only useful on Linux systems. The version > parameter should have the form X.Y.Z and describes the smallest version of > the Linux kernel the generated library is expected to support. The higher > the version number is, the less compatibility code is added, and the faster > the code gets. > > > Sincerely, > > William Harrington > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://linuxfromscratch.org/pipermail/lfs-dev/attachments/20130821/6fb8f2f4/attachment-0001.html > > ------------------------------ > > Message: 19 > Date: Wed, 21 Aug 2013 22:42:08 -0700 > From: Bryan Kadzban <br...@kadzban.is-a-geek.net> > Subject: Re: [lfs-dev] Host System Requirements > To: LFS Developers Mailinglist <lfs-dev@linuxfromscratch.org> > Message-ID: <5215a4b0.8060...@kadzban.is-a-geek.net> > Content-Type: text/plain; charset="iso-8859-1" > > William Harrington wrote: > > > > On Aug 21, 2013, at 21:49, Bryan Kadzban > > <br...@kadzban.is-a-geek.net> wrote: > > > >> So if the host is running 2.6.28 or something, then entering the > >> chroot probably isn't going to work when chapter 5's libc was built > >> with --enable-kernel=2.6.34. > > > > The first error will be in ch5 during gcc pass2 > > ...Oh right, because lots of configure scripts are going to try to exec > binaries linked against /tools/lib*/libc.so.6, which is going to abort > this way. (Most of the binaries are going to have been built by that > same configure script, actually.) > > Has anyone tested this? Or would it be safe to just bump up the host kernel to 2.6.34? Thank you for your gracious answers! Sincerely, JC C
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
