x86_64 build method

[Jeremy Huntwork]

Hello Everyone,

I'm trying to decide how best to alter the x86_64 branch. If we adopt 
the basic principles from DIY-Linux, it would mean that as far as build 
instructions go, we only have to add 3 things:

* Add --disable-multilib to each build of GCC (this has no effect on a 
x86 build)
* In GCC pass 2, adjust the multilib spec, MULTILIB_OSDIRNAMES. DIY just 
removes this completely.
* Add the symlinks /lib64 -> /lib and /usr/lib64 -> /usr/lib

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? If we did, for 
the latter two additions we could add a uname test before the command.

Personally I favor making them one book, but were we to do that, we 
would have to rethink a few things:

1) The way the text reads when it speaks about target triplets and 
dynamic linkers and the appropriate names for these. For x86_64, the 
dynamic linker is ld-linux-x86-64.so.2 and the target triplet is usually 
x86_64-unknown-linux-gnu.

2) The commands to adjust the gcc spec file would have to change to 
incorporate either dynamic linker. (Also, the current command in chapter 
5's adjusting the toolchain, "gcc -dumpspecs | sed 
's@^/lib/ld-linux.so.2@/tools&@g' \", assumes that we will find the name 
of the dynamic linker at the beginning of the line. In x86_64, this 
isn't the case.

3) The toolchain tests would have to be changed to reflect the output of 
either testcase. Usually this is because the output of the test involves 
the name of the dynamic linker or the target triplet.

Lastly, we would want to test to see if someone is building natively 
from a CLFS host that doesn't include /lib64 or /usr/lib64. If they are, 
it's a simple matter of adding those symlinks before starting the build.

Even with all the above, it seems much simpler than trying to maintain 
two separate books.

--
JH