Right now, I am still trying to figure out why I can't successfully build a current version of gcc (3.4.4) and glibc (2.3.5) using a 2.4 kernel.

Sure, I can understand that I might need to boot into the 2.6 kernel and that I might then be able to do some rebuilding only in an environment where that kernel is running, but ... what's the magic ./configure formulas for getting to that point? (In other words, I'm still on the host, and it's 2.4, and I'm building the toolchain.

It's a chicken-or-the-egg problem and I am seeking a solution simply to undertand the salient issues involved. (LFS is a wonderful learning tool for many, many different reasons.)

My opine is thus: It stands to reason that I should be able to build a gcc, and a glibc, sufficient to build my new kernel, without running into dependencies having to do with "2.6 only" stuff. (Obviously, the most significant of these changes being threading.) Let us assume that I have obtained the "linuxthreads" tarball and have placed it into the "glibc" directory.) I mean, after all, you just have to be able to do it, or no one could have done it the first time.

Are there some really-good websites that talk about gcc/glibc on a technical level?

Building gcc-3.4.4 and glibc-2.3.5 is not a problem if you have a 2.6 kernel running on your host system. Why can't you update the kernel running on your host?

Well, as I said, "it's buggin' me now." Or rather, the fundamental question has become to me what LFS is so good at ... a learning exercise.

Any ol' bobbin can grab a pre-existing kernel, say from a CD-ROM, and install it. But I want to move from point-A to point-B without reliance upon such "magic."

Obviously, "getting a 2.6 kernel underneath you somehow" is a fundamental requisite step to a lot of things. The kernel that you start with might not be the kernel that you intend to use for any length of time, but it would be a start.

Is it possible to compile a 2.6 kernel using the gcc (say 3.2.3) and glibc versions (say 2.3.2) that might already be available on the host system?

Yes, of course. You should really be familiar with compiling a kernel and have a good config that you know works with your hardware before you do LFS. LFS won't work if you can't boot with the kernel you compile at the end.

Okay, that wasn't clear to me because I hadn't worked with 2.6 before. (I know that it has a lot of welcome changes to the /dev structure...)

So, having my bootable CD-ROMs firmly and safely in-hand, of course ... ... a workable strategy for a 2.4 -> 2.6 upgrade within LFS would be to:

• Build a new, "temporary" 2.6 kernel on the host-system.
• Place it alongside the existing one.
• Boot into it.
• Construct the new LFS system, with its final 2.6 kernel, while running under the 2.6 kernel.

The "final" kernel, also 2.6, would be built using the updated gcc/glibc that can only be constructed when running under the "temporary" 2.6. For a good, long healthy while, /boot would contain the original kernel 2.4, the temporary kernel 2.6, and the final kernel 2.6.

Thanks. This explains a lot of things.

Indeed, that's exactly right. If you build a monolithic kernel with no modules you don't need to install the modules on your host system, the kernel is just a single binary that can be put anywhere that's convenient.

Hmmm... are you saying that modules would present a problem during the transition? I had not thought about it until you said it, but would the modules generated during the new kernel-generation overwrite the modules used by the old host version? (Obviously that would spell disaster.)

They don't, though, do they? They're in /lib/modules/kernelversion/ ...?"

Well some people like modules but I think they're more trouble than they're worth. The book recommends building a monolithic kernel. http://www.linuxfromscratch.org/lfs/...08/kernel.html It's harder to work out the right kernel config if you're building a monolithic kernel but it is (in my opinion) worth the trouble. Kernel compiling is a lot quicker if you just compile the features you need. If you enable everything as a module just in case you need it it can take hours to compile it all.

Sage advice, then. I'll be quite honest that udev, and to a lesser extent hotplug, are the two things about 2.6 that I'm worried the most about, simply because at this point in time I understand them the least. Since I'll be building the kernel twice anyway, I guess I'll let the computer start chugging away on this compiling chore while I read more about it.

To follow-up this thread...

It is, indeed, impossible to build this glibc library version while running a 2.4 kernel. You have to compile, install, and boot a 2.6 kernel (which you can do, using the 2.4 environment), in order to do the next steps.

But... also to follow-up what happened next... a LiveCD would have been a considerably easier path. The glibc installation dropped down half-finished and created a rather lengthy cleanup process. Yeah, I cheerfully confess, I tried to swap the library of a running system in-place, just like mamma told you not to do. So here I am, telling you not to do it either. Very educational if you care to try it, but not an experience worth repeating.

I like your attitude about learning things and not taking the easy path, but its also important to evaluate effort vs reward... =)

You know what they say about "the journey is the reward?" It's true in this case. You try something, then try to figure out why it didn't work, and you've got a distro to fall-back on. Quite a painful learning process at times, but a good one. Definitely something to do only on a machine that you have set-aside specifically for this purpose.