x86_64

[Greg Schafer]

On Thu, Sep 07, 2006 at 02:47:16PM +1000, Greg Schafer wrote:

> It's only early days but I expect pure x86_64 can be added to the current
> Ref' Build without too much fuss.

Ok, well it seems to work fine. That is - building a pure 64 bit DIY system
starting from a native 64 bit distro (ie: the distro is running a 64 bit
kernel and has a 64 bit userland available).

One gotcha that I've found so far is that the GCC-Pass2 still searches for
libs on the host. This broke my build from an Ubuntu host because:

 - bash's configure prefers libtermcap over libncurses
 - Ubuntu supply a /usr/lib/libtermcap.so pointing at libncurses.so
 - bash-pass2 links against libtermcap.so on the host thus ending up with a
   libncurses.so.5 DT_NEEDED entry.
 - DIY does not build shared ncurses libs in the Temptools phase
 - bash-pass2 won't run due to missing libncurses.so.5
 - DIY currently uses CONFIG_SHELL so the m4 configure craps out

Follow all that? Congrats if you did :-) Anyhoo, the problem is that GCC is
generating -L options pointing at the host eg: -L/lib/../lib64. These can be
seen in the "gcc -v" output. Hmmm, I was a bit surprised by the ../lib64
because this GCC was configured with --disable-multilib. It seems that even
with --disable-multilib, GCC still generates the variously applicable
multilib specs (seen in the gcc -dumpspecs output). Looking into it deeper,
it seems the GCC driver (gcc.c) behaves differently in the presence of the
"multilib" spec when adding dirs to search for libs. This could be a GCC
buglet. Anyway, the solution is to ensure the "multilib" spec is empty.
Simplest way I've found to achieve it for GCC-Pass2 is to:

sed -i.bak '/MULTILIB_OSDIRNAMES/d' gcc/config/i386/t-linux64

This leads me on to another interesting point.. How best to handle the
lib/lib64 debacle? It seems lib64 is hardwired into all the toolchain
components (binutils, gcc and glibc). but lucklily it's not that hard to
change. However, for the standard non-multilib native build, I feel it's
best to simply supply a couple of lib64 symlinks pointing at lib in
/temptools, /lib and /usr/lib. This way, all the build commands remain
compatible with X86 and PPC and everything just works! Incidentally, this is
also how Ubuntu handle it, but they also supply some x86 libs in lib32.
Anyhoo, this will all become clearer when I soon commit the x86_64 changes.

One last thing is the well known Grub issue ie: it's not compilable in pure
64 bit mode. Some folks are apparently using Lilo instead. I'll probably add
Lilo as an option. Tho' it's not at all hard to simply keep on using the
host's boot loader. Boot loaders are a strange beast if you think about it,
they don't actually run in the OS, they run before the OS has booted. Tho'
at least in the case of Grub, you have to *install* it under the OS. Or do
you? In fact, this is one of my pet peeves. The Grub docs specifically
recommend that it be installed under its own *native* environment. That is
with no OS running, either from floppy (or possibly USB or CD?). This is a
point that most folks miss. Oops, I'm starting to rave..

Regards
Greg