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....

1.6? You either really enjoy old school or you're referring to a different book than I'm thinking of.

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.

Pray tell, why? When this new release of Linux was contemplated, how did they avoid the "which came first, the chicken or the egg" paradox?

I surmise that 2.6 requires the Native POSIX Threads Library (NPTL)?

If indeed I must "join 'em rather than beat 'em," what's the appropriate way to proceed? Exactly...

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.

Okay... that's what I thought. :)

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.)

Another question...

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? :confused:

(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! :rolleyes: