Please clarify... LFS 1.6 from a 1.4 starting point?
Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Please clarify... LFS 1.6 from a 1.4 starting point?
As many are doing, I'm trying to move a (Red Hat 8.0) 1.4 system directly to LFS 1.6 and it's giving me trouble. The toolchain "glibc" does not compile and various other issues.
Booting a 1.6 CD-ROM is really not an option in this case.
Last time I did an LFS, I was able to follow "cookbook" directions but not this time. What kernel-headers should I be compiling with, either for the toolchain or for "live?" What ... exactly ... are the changes in procedure (from what is published in the LFS 6 book) that I need to deal with?
I see the other similar threads but they don't seem to really get quite to the brass-tacks....
I think 1.4 and 1.6 referes to kernel versions 2.4 and 2.6 respectively, assuming that, the answer is you MUST use a 2.6 kernel on the host system to build the current version of LFS. Nptl enabled Glibc wont build without it.
I surmise that 2.6 requires the Native POSIX Threads Library (NPTL)?
Nope, therefore no paradox, a linux kernel doesnt require glibc at all to run.
If your system currently runs a 2.4.x kernel with an older linuxthreads type of glibc, all you need to do is upgrade the kernel to 2.6.x, and then you can build an LFS 6.0 system.
Now, step 5.8 in the current build instructions (toolchain) have me constructing a glibc, with the NPTL option enabled, and I find that it will not build under 2.4. Is it therefore necessary to (a) use that glibc; and/or (b) to enable NPTL support in the toolchain builds? All that I need to do first is to successfully get a 2.6 kernel running, "stable enough to stand on" so to speak.
Some documentation makes reference to the new 2.6 "udev" programs, saying that the glibc build had to be this way. (I obviously do not want to try to bring-up the 2.6 kernel and find that it won't go in.) The 2.6 device-management system is altogether new to me.
When I did LFS last time, admittedly some time ago, there were of course no issues in building the newer glibc and running it under both the older kernel version and the newer one. I don't have any problems with the idea of building glibc twice and/or of having the several versions lying around. (In fact, one usually does.) But I do need to be certain that when everything's ready to fly it will actually work. Once I have a 2.6 kernel up-and-running underneath my system I'll be much more comfortable.
Tell me... am I flagellating myself here? Is a CD-ROM Boot approach "the right thing to do?" (I've never done that: I literally built from scratch.)
When attempting to compile "glibc," with the "linuxthreads" add-in, intended as preparation for bringing-up a 2.6 kernel, I am now getting compile-errors during the make: "_errno" is undefined, etc.
"_errno," of all things?
(My intention is to get to the point of having a buildable 2.6 kernel, so that I can boot that and proceed, building the full glibc with the new threading-support ex post facto.)
I see references to this on google-searches, but ... what's going on here? Why on earth would glibc throw undefined symbols, let alone one like "_errno?" (Of all the symbols that I'd expect to always be defined, this one's high on the list.) This sort of goofball stuff is altogether new to me. (Maybe I didn't know how good I had it last time.) I'm sure I'm "doing it right" but, whazzup?
Many aTdHvAaNnKcSe("thanks in advance") ! I really am, umm,learning a lot here!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.