On Wed, Jul 25, 2007 at 05:45:48PM -0400, Ivan Kabaivanov wrote: > > The only big issue is 32bit vs 64bit. As someone already mentioned > previously > in this thread, there are almost nil benefits in building a 64bit userland. > Very few applications can make use of being compiled 64bit. So on ultrasparc > (64bit sparc) I've always done what the ultrasparc gurus have suggested for > many years, 32bit userland + 64bit cross compiler and 64bit kernel. So if > you decide to support x86_64 you'll end up needing a cross compiler just for > the kernel. Oh, and you don't actually need multilib glibc either if you go > with pure 32bit/pure 64bit userland. Even though 64bit CPUs sold outnumber > 32bit CPUs sold at the moment, the installed base of 32bit CPUs is far larger > than 64bit CPUs. So I suggest LFS remain for the foreseeable future purely > 32bit userland. > For "traditional" 64-bit platforms, that is true. On my own mac G5 (which needs a 64-bit kernel), the only real benefit of multilib is that I get to run the testsuite on the kernel compiler. OTOH, I get to say "this one goes up to 64 ;)". Having said that, I don't actually notice that the 64-bit parts of my desktop (that would be gimp, gnumeric, kde, the audio apps, and icewm on multilib) are slower, nor do I notice that the 32-bit desktop as a whole is any more responsive to e.g. changing the active window - in fact if anything it *feels* slower with 32-bit userspace. But enough of "traditional" multilib 64-bit platforms, I'm not about to propose that ppc64 be added to LFS ;-)
For x86_64, the situation is very different. The problem with x86 is that it lacks registers, so gcc produces slow code. With x86_64, the code is faster. A 64-bit kernel also appears to avoid the problems of accessing large amounts of memory (I say "appears" because none of my boards have more than 2GB of memory, and hardware or bios limitations have been reported several times on lkml). For sure, it avoids the whole idea of "highmem" and "bounce buffers" in kernelspace. I was hoping that this discussion would be deferred until after the holiday season. If not, I guess I'll have to come down in the "64 bits good, 32 bits less good" camp for x86|x86_64. The LFS family of projects are all about learning and *building* the software. Building multilib can be an aggravation - the base system has to build packages with libraries in both sizes (for LFS we could argue about a few of them, but the problem is that *somebody* will find an application that they want to build in the other size), and inevitably that sometimes means wasting time by installing the associated programs from the first size and then overwriting them with the programs from the second size. Sure, the base system is not a big deal, it just takes longer. The real multilib fun is in BLFS - can you say "gdk-pixbuf-query-loaders" or "gnome servers" ? I'm tempted to suggest that this would be a good time to put ppc (32-bit only) back into the book, but I'm not sure if there is a big enough user base to make that worthwhile ? ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
