x86_64 again...

Ken Moffat ken at kenmoffat.uklinux.net
Fri Jun 24 12:53:42 PDT 2005

On Fri, 24 Jun 2005, Jens Olav Nygaard wrote:

> Please bear over with me if this has been pointed out before...
> I'm running LFS+BLFS (fairly recent stuff, Jan 05) on an Intel P4 thingy.
> Now I'm awaiting a shiny new AMD X2 in the mail. My question is
> this: What is the best (=most sure to succeed with stable results) way to
> get a 64 bit LFS running?

 At the moment, the "most sure" was is probably to install a 64-bit
distro.  So far, there are no _recent_ x86_64 instructions that I'm
aware of for building from an x86 host.  In LFS terms, "best" means
maximising the learning, but it depends how long you can spare.

 Ignoring _how_ you are going to install, you need to consider what sort
of result you want - my experience is that browser plugins (RealPlayer
in my case, but also flash) need a multilib system so that they can link
against 32-bit libraries (RealPlayer needs the gtk/atk/pango trinity,
and when you work backwards this implies a 32-bit X and libpng (you can
overwrite the 32-bit X _programs_ with a later 64-bit build).

 Similarly, the common bootloaders are 32-bit (I think Chris Lingard
patched lilo or one of its dependencies to build on a 64-bit host, but I
could be wrong).  Obviously, you can install the bootloader from a
32-bit host, but long-term that's not a viable solution.

 After you've (hopefully) got LFS installed, you'll want to build
whatever blfs packages you use.  If the 32-bit stuff is in /lib and
64-bit in /lib64, you'll need to take care (as well as jumping through
some minor hoops) - I hope to post some initial comments about specific
packages on blfs-support in the next few days.

 From a BLFS perspective, using /lib for 64-bit would undoubtedly be
easier (and on 86_64 there is no reason to build 32-bit for your normal
applications, the additional registers mean there is no significant size
penalty, unlike e.g. ppc64 where kernel maintainers use a mostly 32-bit
userspace).  But putting the 32-bit stuff into /lib32 means patching at
least some of the toolchain. I'm fairly sure Ryan's cross-lfs scripts
have got something for this, but it was only near the end of my last
test build that I realised what a pain compiling to /lib64 can be in

 So far, I haven't managed a successful x86_64 build without Ryan's
scripts, and even hacking Ryan's scripts to look nearer LFS-6.1 gave me a
somewhat broken result, mainly because I don't grok everything in the
scripts.  But, it's a learning experience [ spoken through gritted teeth
;) [

 das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-support mailing list