x86_64 build method
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
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
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