x86_64 build method

Ken Moffat ken at linuxfromscratch.org
Wed Jul 25 16:07:57 PDT 2007


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



More information about the lfs-dev mailing list