x86_64 build method

Ivan Kabaivanov chepati at yahoo.com
Wed Jul 25 14:45:48 PDT 2007

On Tuesday 24 July 2007 12:10, Matthew Burgess wrote:
> On Tue, 24 Jul 2007 11:59:39 -0400, Jeremy Huntwork 
<jhuntwork at linuxfromscratch.org> wrote:
> > Matthew Burgess wrote:
> >> On Tue, 24 Jul 2007 11:40:24 -0400, Jeremy Huntwork
> >
> > <jhuntwork at linuxfromscratch.org> wrote:
> >>> The question is, do we want x86_64 to be a separate book, or simply
> >
> > roll
> >
> >>> these small changes into a conglomerate book with x86?
> >>
> >> I'd certainly prefer them to be in the same book,
> >
> > My biggest problem with this approach is that it gets to be a nightmare
> > to edit. But, it is do-able.
> Hmm, that "nightmare" seems a bit extreme.  Certainly, for native x86-64,
> which is the only additional target we're contemplating at the moment,
> having 2 paragraphs (or small sections at the most) in the book surrounded
> in the relevant profiling syntax, doesn't seem too onerous to me.  Once in
> there, I doubt they'd need amending much - probably only if newer GCC
> versions change relevant portions of the specs file.
> Of course, if more targets are desired in the future, our approach may well
> need to change, but for now I think x86 & x86-64 native builds capture the
> largest section of the LFS audience and anyone else can continue on to
> Regards,
> Matt.

Speaking from experience building LFS on x86, ppc (32bit) and sparc (both 32 
and 64 bit), except for the dynamic linker and the boot loader, there is 
little to no difference in the instructions when building on different 
architectures.  So with minimal effort the book can be modified to apply 

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.

Ideally, parts of CLFS would be merged into LFS.  I never understood the need 
for CLFS.  Presumably it was for people like me who were building LFS on 
non-x86 architectures.  But CLFS is just complicating what is a rather simple 
procedure.  The only useful things in it are the extra packages needed for 
different architectures.  And the instructions to build a cross compiler.  
Everything else is just LFS.

I understand the reluctance of the LFS devs to explicitly "support" non-x86 
build as someone has to spend the time and effort to test the instructions on 
those other architectures.  But I still maintain that since you're discussing 
the inclusion of x86_64, you might as well consider modifying the 
instructions minimally so that, even if the book doesn't mention non-x86, the 
instructions will still work.  I'm talking about the dynamic linker and the 
sed command fixing the gcc specs.


More information about the lfs-dev mailing list