AUTHOR: Ken Moffat <ken@kenmoffat.uklinux.net>
DATE: 2005-08-16
LICENSE: MIT License
SYNOPSIS: Building a pure64 x86_64 system from i686 using LFS-6.1
DESCRIPTION: Building a 64-bit system (with libraries in /lib, not
/lib64) from i686, using cross-compiling.

PREREQUISITES: amd64 or emt64 system with LFS-6.1 (i686) installed
and running, or something similar (recent 2.6 kernel, gcc-3.3 or 3.4,
sed which accepts '-i'.  Posts over the years on lfs-support suggest
that a version of e.g. fedora with _newer_ gcc|binutils|glibc than
those in the 6.1 book will cause grief.  This is targeted at 
experienced users of LFS, and refers to the LFS-6.1 book.

HINT:


Overview
________

 This is very much work in progress - the early parts of the build
have a few rough edges, and I don't support 32-bit binaries or
applications (hello, grub!) at the moment, but the end result works.

 At the moment, there is a tendency for the glibc testsuite to hang
on one of my boxes (my main development box :-( ), but it seems to
work ok after interrupting and repeating the build.  There are also
failures in the gettext tests which suggest that not everything is as
it should be.  Anecdotal evidence is that building the native glibc on
a 2.6.12.x kernel works, building on 2.6.11.x hangs the first time -
I have no idea *why*. 

 This isn't an official LFS hint - everything moves on, my purpose
was to get an LFS-6.1 64-bit build working.  That is achieved with
the exception of passing gettext's testsuite.  Now I'll be 
concentrating on the cross-lfs book, particularly the pure64 part.


Let's start by asking a few questions:

Why am I writing this ?

 Easy - I couldn't find a _current_ guide to doing this from the
same host running i686.  I didn't want to install an x86_64 distro
just to bootstrap an LFS build when I had a perfectly good 32-bit LFS
system to do it.  The cross-lfs book should get an honourable
mention, but it's hoping to become LFS-7 (so, it uses _newer_ 
packages) and anyway it was multilib (lib and lib64) at the time.

Why run x86_64 if you don't have more than 4GB of memory ?

 The x86_64 model provides twice the number of registers, which makes
things a lot easier for the compiler and is often thought to make
programs run about 20% faster - certainly, compiling the bigger blfs
packages is noticeably quicker.  On my desktop, running parallel tests
(one to do photo manipulation of .nef and .tif files with ufraw and
ImageMagick, the other to oggenc some .wav files) the elapsed time was
about 30% less.  Some programs show huge improvements (e.g. 'openssl
speed'), others less, and benchmarks in bonnie are mixed (character
i/o faster, block i/o slower, but both very variable from one run to
the next).  

But why not multilib ?

 In the beginning, I thought that /lib for 32-bit and /lib64 sounded
exciting and cool, plus it's what some of the big distros do.  
Unfortunately, I want to run 64-bit as my normal architecture (unlike
e.g. ppc64 where 32-bit ppc userspace is usually preferred for size
reasons - the size of x86_64 installs is only 10% or 20% bigger
(unstripped) than i686.  This means remembering to tweak every blfs
package that installs files in lib.  Some respect --libdir, a few
don't.  This build will *not* run 32-bit binaries.


Other differences from the cross-lfs book:

 Because the audience is more focussed, we can get by with building
rather less in the target phase, but of course we have to build a
kernel and reboot, even though we are esentially on the "if you are
going to chroot" path.  Also, the target audience can use "sed -i"
from the start. 

 The build order for native tools aims to follow the 6.1 book, with
lilo added at the end.

 Cross-lfs has dropped hjl-binutils, but we have to build bison, flex,
and m4 in the target phase.


0. Summary of the process
_________________________


 We begin by cross-compiling a toolchain.  We use that to build
native tools which replace most of the LFS book's "temporary tools".
Then we build a non-modular kernel.  After we've booted that, we
chroot into the new system.

 So far, we haven't been able to test any of the tools (i686 can't
run x86_64 binaries), so being able to chroot is a hopeful sign.
At least we can use the host's X environment (if installed) to make
things more comfortable for ourselves.

 It is perhaps worth noting that while I was developing my scripts
I inadvertently started over while running an x86_64 kernel - to my
considerable surprise, the build completed, so I guess I've at least
got sufficient --host and --target specifications.

 The observant will notice that I said "replace most of" just now -
there are a few things that don't cross-compile well, or just cause
too much grief, so we build them now.  Because you have to be root
to chroot, there are also some minor changes for the temporary tools
to drop the $LFS.

 After that, we run the rest of the LFS build more-or-less unchanged.
We have to build binutils twice, just as if we'd deleted the pass2
directories in a straight build, but otherwise the biggest difference
is that grub passes -m32 to gcc during it's configure, which of course
fails on a non-biarch gcc.  So, we use lilo.

 I'll also offer a few comments on blfs for the desktop.

 The patches are a mixture of what is in LFS-6.1, perhaps some other
toolchain modifications from lfs.patches, and a few specially for this
approach.  The non-standard patches should all be available at
http://www.kenmoffat.uklinux.net/patches and some of them may also be
available from the lfs.patches project.


1. Cross-compiling
__________________


 In the same way as regular LFS uses /tools as a symlink to a
temporary system, I use symlinks for the cross-toolchain
(/cross-tools) and the target tools (/tools).  My preference is to put
both of these onto the new filesystem, so as root

	ln -s /mnt/lfs/cross-tools /cross-tools
	ln -s /mnt/lfs/tools /tools
	and of course mount the filesystem.

 As user lfs, do the usual set +h, umask, LC_ALL stuff, but set the
PATH to /cross-tools/bin:/bin:/usr/bin, then export LFS, LC_ALL, PATH
and unset CC CXX CPP LD_LIBRARY_PATH LD_PRELOAD.

 There are a few more things to export (obviously, if you aren't
scripting this, you can get away with just setting them).

	export TARGET=x86_64-pc-linux-gnu
	export TGT_CFLAGS="-O2 -march=athlon64"
	export BUILD=i686-pc-linux-gnu
	export ARCH=x86_64

 The TARGET and BUILD specifications are pretty standard
cross-compile stuff, but be aware that although most packages use the
--host --target --build flags, the values they expect can vary.  The
TGT_CFLAGS are safe for the toolchain.  ARCH is what the kernel
recognses.

 If you are comparing this to other scriptable cross-compiles
note that some people may use a variable name like 'HOST' where I use
'BUILD' - basically, cross-compiling uses the build-host-target flags,
but not every package uses the same values (compare glibc and gcc).

 The headers go into /tools ready for the native tools, but all of the
coss-compiling tools go into /cross-tools/${TARGET}/bin - they may
also be hardlinked as /cross-tools/bin/${TARGET}-progname, which will
come in handy when we cross-compile the kernel.


1.0 linux-libc-headers-2.6.11.2

 We need 64-bit kernel headers before we can build cross-binutils.

	install -d /tools/include
        cp -R include/asm-${ARCH} /tools/include/asm
        cp -R include/linux /tools/include

 Note that we've installed these into /tools, ready for the target.


1.1 binutils-2.15.94.0.2.2
[ 1.0 SBU, 141.4 MiB gross, 14.8 MiB net ]

	mkdir ../binutils-build
	cd ../binutils-build
	../binutils-2.15.94.0.2.2/configure --prefix=/cross-tools \
	--target=${TARGET} --host=${BUILD} \
	--disable-nls --enable-shared --enable-64-bit-bfd \
	--disable-multilib --with-lib-path=/tools/lib

	make configure-host

	make headers -C bfd

	make

	make install

	cp ../binutils-2.15.94.0.2.2/include/libiberty.h \
	 /tools/include


1.2 glibc-2.3.4-headers

 We're now getting into the cross toolchain, and everything depends on
everything else!  First extract the headers from glibc so that we can
compile some sort of gcc.

 apply the glibc-2.3.4-amd64_lib-2.patch to fix the RTLDLIST so that
ld-linux-x86-64.so.2 is in /lib not /lib64 - the patch also references
lib2, but that is irrelevant when we only build a 64-bit toolchain.

 This patch came from debian's pure64 list, via Theo Schneider.

	mkdir ../glibc-build
	cd ../glibc-build

	../glibc-2.3.4/configure --prefix=/tools \
	 --host=${TARGET} --build=${BUILD} \
	 --without-cvs --disable-sanity-checks \
	 --enable-kernel=2.6.0 --with-headers=/tools/include \
	 --with-binutils=/cross-tools/${TARGET}/bin

	make install-headers

	install -d /tools/include/bits
	cp bits/stdio_lim.h /tools/include/bits
	touch /tools/include/gnu/stubs.h
	cp ../glibc-2.3.4/nptl/sysdeps/pthread/pthread.h /tools/include
	cp ../glibc-2.3.4/nptl/sysdeps/unix/sysv/linux/${ARCH}/bits/pthreadtypes.h \
	 /tools/include/bits
	
 Most of the work is done by install-headers, but it doesn't copy over
one of the bits files.  We need a gbu/stubs.h file, but it can happily
be empty.  Lastly, we copy over the nptl threading headers.


1.3 gcc-3.4.3-static

 Chicken-and-egg time with libgcc - the first run doesn't produce
libgcc_eh.a, nor libgcc_s.so : according to Ryan, the gcc_eh objects
are packed into libgcc.a.

 Apply the gcc-3.4.3-specs-pure64-1.patch,
	   gcc-3.4.4-cross_search_paths-1.patch

 The specs patch is a modification of hte regular LFS specs patch,
using lib and lib32 instead of lib64 and lib.  The amd64_lib patch
is from the Debian pure64 list via Theo Schneider, and similarly
corrects the directories.  Mostly not needed in the cross-compile,
but if I move to lib plus lib32 it will fix the multilib directory
names.

 first, tell gcc that the startfiles will be in /tools/lib

	echo "
#undef STARTFILE_PREFIX_SPEC
#define STARTFILE_PREFIX_SPEC \"/tools/lib/\"" >>gcc/config/linux.h

 next, point the header directory to /tools/include

	sed -i "s@\(^CROSS_SYSTEM_HEADER_DIR =\).*@\1 /tools/include@g" \
           gcc/Makefile.in 2>$LOG &&
 
	mkdir ../gcc-build >>$LOG 2>&1 &&
	cd ../gcc-build 

	CFLAGS="-O2 -pipe" \
	../gcc-3.4.3/configure --prefix=/cross-tools \
	 --host=${BUILD} --target=${TARGET} \
	 --with-local-prefix=/tools --disable-nls \
	 --disable-shared --disable-multilib \
	 --enable-languages=c

	make all-gcc
	make install-gcc

 These targets are commonly referenced in cross-compiles, but so far I
haven't found any explanation of them.


1.4 glibc-2.3.4-startfiles

 Use the first compiler to create crt[i1n].o.

 Again apply the glibc-2.3.4-amd64_lib-2.patch

	mkdir ../glibc-build
	cd ../glibc-build

	echo "libc_cv_forced_unwind=yes"  >config.cache
        echo "libc_cv_c_cleanup=yes"     >>config.cache
	BUILD_CC=gcc BUILD_CFLAGS="-O2 -pipe" \
        CC="${TARGET}-gcc -m64 $TGT_CFLAGS" \
        AR=${TARGET}-ar RANLIB=${TARGET}-ranlib \
        ../$glibc-2.3.4/configure --prefix=/tools \
         --host=${TARGET} --build=${BUILD} \
         --without-cvs --disable-profile \
         --enable-add-ons --with-tls --with-__thread \
         --enable-kernel=2.6.0 \
	 --with-binutils=/cross-tools/bin \
         --with-headers=/tools/include \
         --cache-file=config.cache

	make csu/subdir_lib

	install -d /tools/lib
	cp -fo csu/crt[i1n].o /tools/lib



1.5 gcc-3.4.3-shared

 Ok, now we can build libgcc_eh - we get this by reinstalling gcc, so
that it overwrites the earlier version with a slightly larger set of
files.  Begin as before :

 Again apply the gcc-3.4.3-specs-pure64-1.patch,
	   gcc-3.4.4-cross_search_paths-1.patch

	echo "
#undef STARTFILE_PREFIX_SPEC
#define STARTFILE_PREFIX_SPEC \"/tools/lib/\"" >>gcc/config/linux.h

	sed -i "s@\(^CROSS_SYSTEM_HEADER_DIR =\).*@\1 /tools/include@g" \
           gcc/Makefile.in 2>$LOG &&

 Now we have to stop it trying to link against libc.so because we
don't have that yet.

	sed -i '/^SHLIB_LC = /s@-lc@@ \
	 gcc/config/t-{slibgcc-elf-ver,libunwind}
 
 Stop it from picking up the host's header files

	sed -i '/FLAGS_FOR_TARGET.*\/lib\//s@-B[^ ]*/lib/@@g' \
         configure configure.in

	mkdir ../gcc-build >>$LOG 2>&1 &&
	cd ../gcc-build 

	CFLAGS="-O2 -pipe" \
        ../gcc-3.4.3/configure --prefix=/cross-tools \
        --host=${BUILD} --target=${TARGET} \
        --with-local-prefix=/tools --enable-languages=c \
        --disable-multilib \
        --disable-nls --enable-shared

	make CFLAGS_FOR_TARGET="-march=athlon64" all-gcc
	make install-gcc


1.6 glibc-2.3.4-full

 Now that we have libgcc_eh, we can build glibc.

 Again apply the glibc-2.3.4-amd64_lib-2.patch

	mkdir ../glibc-build
	cd ../glibc-build

	echo "libc_cv_forced_unwind=yes"  >config.cache
        echo "libc_cv_c_cleanup=yes"     >>config.cache
	BUILD_CC=gcc BUILD_CFLAGS="-O2 -pipe" \
	CC="${TARGET}-gcc $CFLAGS" \
	AR=${TARGET}-ar RANLIB=${TARGET}-ranlib \
	../$glibc-2.3.4/configure --prefix=/tools \
	--host=${TARGET} --build=${BUILD} \
	--without-cvs --disable-profile \
	--enable-add-ons --with-tls --with-__thread \
	--enable-kernel=2.6.0 --with-binutils=/cross-tools/bin \
	--with-headers=/tools/include \
	--cache-file=config.cache

	make
	make install


1.7 gcc-3.4.3-full

 And now we have a libc to link against, we can produce a full
cross-compiler for both C and C++.  Again, we overwrite some of the
files from a previous version.

 Again apply the gcc-3.4.3-specs-pure64-1.patch,
	   gcc-3.4.4-cross_search_paths-1.patch

	echo "
#undef STARTFILE_PREFIX_SPEC
#define STARTFILE_PREFIX_SPEC \"/tools/lib/\"" >>gcc/config/linux.h

	sed -i "s@\(^CROSS_SYSTEM_HEADER_DIR =\).*@\1 /tools/include@g" \
           gcc/Makefile.in 2>$LOG &&

	sed -i '/FLAGS_FOR_TARGET.*\/lib\//s@-B[^ ]*/lib/@@g' \
         configure configure.in

	mkdir ../gcc-build >>$LOG 2>&1 &&
	cd ../gcc-build 

	CFLAGS="-O2 -pipe" \
        ../gcc-3.4.3/configure --prefix=/cross-tools \
         --target=${TARGET} \
         --with-local-prefix=/tools \
         --enable-languages=c,c++ --enable-__cxa_atexit \
         --enable-c99 --enable-long-long \
	 --enable-threads=posix \
         --disable-nls --enable-shared \
         --disable-multilib 

	make CFLAGS_FOR_TARGET="-march=athlon64"
	make install


2. Building for the target system.
__________________________________


Now we use the cross-compiled toolchain to build a target system.  We
will then use this to build a kernel.  This is akin to chapter 5 of
the LFS book, except that we cannot run any testsuites, and a few
packages are best deferred until after we're running a 64-bit kernel.

 Environment as before, with the following additions:

	export CC="${TARGET}-gcc -march=athlon64"
	export CXX="${TARGET}-g++ -march=athlon64"
	export AR="${TARGET}-ar"
	export AS="${TARGET}-as"
	export RANLIB="${TARGET}-ranlib"
	export LD="${TARGET}-ld"

 I've added copious -m64 flags throughout this, I suspect they should
not be necessary, but they're low on my list of things to review.


2.0 binutils-2.15.94.0.2.2

	mkdir ../binutils-build
	cd ../binutils-build

	CC="${CC} -m64" ../binutils-2.15.94.0.2.2/configure \
	--prefix=/tools --libdir=/tools/lib \
	--with-lib-path=/tools/lib --disable-multilib \
	--build=${BUILD} --host=${TARGET} --target=${TARGET} \
	--disable-nls --enable-shared --disable-64-bit-bfd

	make configure-host
	make headers -C bfd
	make install
	cp ../binutils-2.15.94.0.2.2/include/libiberty.h /tools/include

 Note that we already copied libiberty.h during cross-binutils.

2.1 gcc-3.4.3

 apply the following patches
	gcc-3.4.3-specs-pure64-1.patch
	gcc-3.4.4-cross_search_paths-1.patch
	gcc-3.4.4-amd64_lib-1.patch

        echo "
#undef STARTFILE_PREFIX_SPEC
#define STARTFILE_PREFIX_SPEC \"/tools/lib/\"" >>gcc/config/linux.h

        sed -i '/#define STANDARD_INCLUDE_DIR/s@"/usr/include"@0@g' \
         gcc/cppdefault.c

 Next, prevent it trying to use xgcc because we are still
cross-compiling.

echo 'removing use of xgcc' &&
        sed -i "s@\./xgcc@${HST_TOOLS}/bin/${TARGET}-gcc@g" \
         gcc/mklibgcc.in 2>>$LOG &&

 and finally sort out the _native_ system header directory

	sed -i 's@\(^NATIVE_SYSTEM_HEADER_DIR =\).*@\1 /tools/include@g' \
         gcc/Makefile.in

        mkdir ../gcc-build &&
        cd ../gcc-build

         ../$gcc-3.4.3/configure --prefix=/tools \
        --build=${BUILD} --host=${TARGET} --target=${TARGET} \
        --libexecdir=/tools/lib --with-local-prefix=/tools \
	--enable-long-long  \
        --enable-c99 --enable-shared --enable-threads=posix \
	--enable-__cxa_atexit --disable-nls \
        --disable-multilib \
         --enable-languages=c,c++ --disable-libstdcxx-pch

        make
        make install
        ln -sf gcc /tools/bin/cc
        mv /tools/lib64/* /tools/lib
        rm -Rf /tools/lib64 


2.2 gawk-3.1.4


        ./configure --prefix=/tools \
        --build=${BUILD} --host=${TARGET} --target=${TARGET
	make
	make install

2.3 coreutils-5.2.1


echo "utils_cv_sys_open_max=1024" >>config.cache
        DEFAULT_POSIX2_VERSION=199209 \
        ./configure --prefix=/tools --cache-file=config.cache \
        --build=${BUILD} --host=${TARGET}

        make
        make install


2.4 bzip2-1.0.3


 remove the tests

	sed -i -e 's@^\(all:.*\) test@\1@g' \
	 Makefile 

 In general, because we have already set CC, AR, and RANLIB we don't
need to pass them to configure or set them when invoking make.  Bzip2
is an exception, if we don't set them it will build 32-bit linked
using a non-existent /tools/lib/li-linux.so.2 for its linker.

	make CC="${CC}" AR=$"{AR}" RANLIB="${RANLIB"
	make PREFIX=/tools install


2.5 gzip-1.3.5

 tell configure it will have to use cross-compiled tools

	sed -i "s@nm conftest@${TARGET}-&@" configure

	./configure --prefix=/tools \
	--host=${TARGET} >>$LOG 2>&1 &&

	make
	make install


2.6 diffutils-2.8.1


	./configure --prefix=/tools \
	 --host=${TARGET}

	make
	make install


2.7 findutils-4.2.20

 when cross-compiling, configure can't find getline

	echo "am_cv_func_working_getline=yes" >> config.cache

	./configure --prefix=/tools \
	--cache-file=config.cache \
	--host=${TARGET}

	make
	make install


2.8 make-3.80


	./configure --prefix=/tools \
	--host=${TARGET}

	make
	make install


2.9 grep-2.5.1a


	./configure --prefix=/tools \
	--disable-perl-regexp \
	--host=${TARGET}

	make
	make install

 
	./configure --prefix=/tools \
	--host=${TARGET}

	make
	make install



2.10 sed-4.1.4


	./configure --prefix=/tools \
	--host=${TARGET}

	make
	make install


2.11 gettext-0.14.3

 again, configure can't find getline

	echo "am_cv_func_working_getline=yes" >> config.cache

	./configure --prefix=/tools \
	--disable-libasprintf --without-csharp \
	--cache-file=config.cache --host=${TARGET}

	make
	make install


2.12 ncurses-5.4


	./configure --prefix=/tools --with-shared \
	--host=${TARGET} --without-debug --without-ada \
	--enable-overwrite --with-build-cc=gcc \

	make
	make install


2.13 patch-2.5.4


	./configure --prefix=/tools \
	--host=${TARGET}

	make
	make install


2.14 tar-1.15.1

 apply the tar-1.15.1-sparse_fix-1.patch.

 again, configure can't find getline

	echo "am_cv_func_working_getline=yes" >> config.cache

	CC="${CC} -m64" \
	./configure --prefix=/tools \
	--cache-file=config.cache \
	--host=${TARGET}

	make
	make install


2.15 bash-3.0

 apply the bash-3.0-avoid_WCONTINUED-1.patch

 use the cross-compiled binutils version of 'size' to show the size of
bash:

	sed -i "s@size \$(Program)@${TARGET}-&@g" Makefile.in

	./configure --prefix=/tools --without-bash-malloc \
	--host=${TARGET}

	make
	make install


2.16 m4-1.4.3

	./configure --prefix=/tools \
	--host=${TARGET}

	make
	make install


2.17 bison-2.0

	./configure --prefix=/tools \
	--host=${TARGET}

	make
	make install


2.18 flex-2.5.31

 apply the flex-2.5.31-debian_fixes-2.patch

	./configure --prefix=/tools \
	--host=${TARGET}

	make
	make install


2.19 util-linux-2.12q

	sed -i 's@/usr/include@/tools/include@g' configure
	./configure

	make ARCH="" CPU="" -C lib
	make ARCH="" CPU="" -C mount  mount umount
	make ARCH="" CPU="" -C text-utils more

	cp -v mount/{,u}mount text-utils/more /tools/bin


3.0 linux-2.6.x (temporary)
___________________________

 We're just about ready to reboot to a 64-bit system, but for that we
will need a 64-bit kernel.

 My experiece is that the natve build of glibc hange in its test phase
when first run.  Anecdotal evidence suggests that using a 2.6.12.x
kernel has a better success rate, although I have no idea why.  In
general, using a newer kernel is usually better (more bugs fixed), but
there may be a knock-on effect on the udev rules.  So far, the version
of udev in LFS-6.1 *seems* to work for me. 

 Your existing x86 config is unlikely to be a lot of use (a lot of
things differ), so use menuconfig.

	make CROSS_COMPILING=${TARGET}- ARCH=${ARCH} menuconfig

 You won't be able to load any modules yet, so turn off modules.  Make
sure you select everything you need (e.g. IDE, SCSI, SATA, network,
sound if you want it while you're building the system, usb, cpufreq,
video drivers, filesystems, nfs - whatever is appropriate).  You can
select DRI, but I haven't managed to get it to work with a 64-bit
kernel and 32-bit userspace, so some of the fancy screensavers will
load the CPU.

	make CROSS_COMPILING=${TARGET}- ARCH=${ARCH}

 then as root

	cp ${ARCH}/boot/bzImage /boot

 and set up the bootloader.

 Reboot, then test the kernel to ensure it is sufficiently functional.
If it isn't, reboot to the i686 system, set TARGET and ARCH (or just
remember to type them), alter the config, recompile, repeat.


4. Into chroot, and sanity checks.
__________________________________

 We haven't been able to run tests on the target tools, so this is the
big moment when we find out if they work.  Make sure $LFS is still set.


4.0 Entering chroot


 See sections	6.2 Mounting Virtual Kernel File Systems,
		through
		6.8 Populating /dev
		from the regular LFS book.


4.1 Sanity tests, and tidying up

 We don't yet know if the native compiler works, so its time to run a
test.

	echo 'main(){}' > dummy.c
	cc dummy.c
	readelf -l a.out | grep ': /lib'

 The answer we expect to see is

	[Requesting program interpreter: /tools/lib/ld-linux-x86-64.so.2]


 Like most people, I use scripts to build my systems.  Unlike most,
I've always been keen to measure the space used.  Part of this uses
`df'.  It seems that coreutils won't build df when it's
cross-compiling (or perhaps, when the host is already running a 64-bit
kernel ?).  My attempts to try to force it to build in the target
phase generated all manner of bizarre and unique errors, so for those
who need it we can build it now.

 Reextract coreutils, then

	DEFAULT_POSIX2_VERSION=199209 ./configure --prefix=/tools
	make -C lib
	make -C src
	install -m0755 src/df /tools/bin

 We haven't tested the c++ compiler yet - doing a dummy build of
ncurses is a good test of it - just follow the configure and make
steps from part 6.


5. The remaining temporary tools
________________________________


 I was going to say that these follow the regular book, but because
we're now in chroot the $LFS prefix falls away.


5.1 tcl-8.4.9

	cd unix
	./configure --prefix=/tools

	make

 If you want to test this,

	TZ=UTC make test

 Although I like to test as much as possible after cross-building, I'm
in some doubt about how to interpret the results - I see failures in
various http, socket, and unix tests.  Some of the compilation error
messages make me think that using a 64-bit architecture might be to
blame (i.e. the code or the test suite makes bad assumptions).

	make install
	ln -sf tclsh8.4 /tools/bin/tclsh
	cd ../
	export TCLPATH=`pwd`	

 Unusually, do NOT remove the tcl directory yet.


5.2 expect-5.43.0

 apply the expect-5.43.0-spawn-1.patch

	./configure --prefix=/tools --with-tcl=/tools/lib \
	--with-tclinclude=$TCLPATH

 Note that in chroot --with-x=no should be redundant

	make
	make test

 My experience was that all 25 tests passed.

	make SCRIPTS="" install


5.3 dejagnu-1.4.4

	./configure --prefix=/tools
	make
	make install


5.4 perl-5.8.7

 A version upgrade, detailed on the lfs errata page.

 apply the perl-5.8.7-libc-1.patch

	./configure.gnu --prefix=/tools -Dstatic_ext='IO Fcntl POSIX'
	make perl utilities
	cp perl pod/pod2man /tools/bin
	mkdir -p /tools/lib/perl5/5.8.7
	cp -R lib/* /tools/lib/perl5/5.8.7


5.5 texinfo-4.8

	./configure --prefix=/tools
	make
	make check
	make install


6. Native build of the new system.
__________________________________


 This is almost unchanged from the LFS-6.1 book.


6.1 linux-libc-headers-2.6.11.2

 See section 6.9.1 of the book, but use asm-x86_64 instead of 
asm-i386.


6.2 man-pages-2.01

 See section 6.10.1 of the book.


6.3 glibc-2.3.4

 See section 6.11 of the book, but apply the -fix_test-1.patch and
also apply the -amd64_lib-2.patch which prevents the use of lib64 on
x86_64.

 In the tests, this has a tendency to hang and I've no idea why. If
the system is idle after a few minutes, and a tail on the test log
shows nothing happening in the inet tests (or the console, if you are
not logging it), interrupt it with control-C and repeat.  Because I'm
scripting and my scripts rebuild the first uncompleted package, I
actually begin from the start of glibc after a hang.  Whatever, it
works for me.  As noted near the beginning, tests running on a 2.6.12.x
kernel seem to just run throught.

 I had the expected failure in posix/annexc and everything else passed.


6.4 Temporary binutils-2.15.94.0.2.2

 We don't have a native binutils that we prepared earlier, and we
can't even use one from the temporary phase because we want it linked
against our native glibc, so we have to do a double build.

	mkdir ../glibc-build
	cd ../glibc-build

	./configure --prefix=/usr --enable-shared

	make tooldir=/usr
	make -C ld tooldir=/usr install


	Run the perl command from the book's section 6.12 to edit the
	specfile, but referencing lib/ld-linux-86-64.so.2 instead of
	lib/ld-linux.so.2 in both the 'from' and 'to' parts.

 /usr/bin/ld should now use the correct ld-linux-86-64 from /lib, but
it is still linked against /tools/lib as can be sean by running
readelf -l on it.

	Run the sanity check from the book's section 6.12, it should
	show the program interpreter is now /lib/ld-linux-x86-64.so.2
	

6.5 native binutils-2.15.94.0.2.2

 Follow section 6.13 of the book, but 'make -k check' when running the
testsuite because all versions of binutils on my pure64 builds have 5
errors in the ld and cd tests.


6.6 gcc-3.4.3

 Apply the nofixicludes, linkonce, and amd64_lib patches.  Otherwise
follow section 6.14 of the book and repeat the sanity check.

Note: 

 We will be bootstrapping this because we haven't yet bootstrapped
gcc and bootstrapping is a source of comfort.  Unfortunately, some of
the temporary tools created in this process link against /lib64.  The
gcc-3,4,4-amd64_lib64-1 patch solves this, but in later builds from
this system you may prefer to do a sed like this:

    sed -i -e \
     's%/lib64/ld-linux-x86-64.so.2%/lib/ld-linux-x86-64.so.2%'\
     -e 's%/lib/ld-linux.so.2%/lib32/ld-linux.so.2%' \
      ../gcc-v.v.v/gcc/config/i386/linux64.h

    sed -i 's% ../lib64 ../lib%../lib ../lib32%' \
     ../gcc-v.v.v/gcc/config/i386/t-linux64

just before configuring gcc.  These change the location of the 32-bit
linker to /lib32/ld-linux.so.2 - obviously, we don't have one of
those in this build, but a native build with --enable-multilib=no
works.

 This will apply to gcc-3.4.{3,4} and gcc-4.0.1 bootstraps in ALL
subsequent builds from the new system, whether of a newer system, or
of extra compilers.

 After applying the patches , continue with
 
	sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/Makefile.in

        mkdir ../gcc-build
        cd ../gcc-build

        ../gcc-3.4.3/configure --prefix=/usr \
         --libexecdir=/usr/lib --enable-shared \
         --enable-multilib=no \
         --enable-threads=posix  --enable-__cxa_atexit \
         --enable-clocale=gnu --enable-languages=c,c++

        make bootstrap	
	make -k check
	make install
	ln -sf ../usr/bin/cpp /lib
	ln -sf gcc /usr/bin/cc

 Follow this with a sanity-check compile.

6.7 coreutils-5.2.1

 Follow section 6.15 of the book.

6.8 zlib-1.2.3

 Follow section 6.16 of the book, but upgrade the package to 
zlib-1.2.3 (no patches are required) - this fixes a further
security vulnerability.  Remember to alter the symlink from
/usr to link to the correct version, or perhaps to link to
libz.so.1 which is a symlink maintained by libz's install.


6.9 mktemp-1.5 through 6.21 flex-2.5.31

 Follow sections 6.17 to 6.29 of the book.


6.22 gettext-0.14.3

 Follow section 6.30.  I had 6 test failures in rpath with a
message /usr/bin/ld: cannot find -lrpathz , an as a result
it fails to do the main tests.  Possibly, a misconfiguration
in libtool (upgrading that to 1.5.18 doesn't help).

 Gettext-0.14.1 passes its tests, all newer versions up to and
including 0.14.5 fail.  

6.23 inetutils-1.4.2, 6.24 iproute2-2.6.11-050330

 Follow sections 6.31, 6.32

6.25 perl-5.8.7

 Follow the instructions in section 6.33, but using perl-5.8.7.

6.26 texinfo-4.8 to 6.36 grep-2.5.1a

 Follow sections 6.34 to 6.44

6.37 - ignore grub

As noted, grub will not build in a pure64 environment.  For now, we'll
build lilo and its dependencies at the end of chapter 6.

6.38 gzip-1.3.5 through 6.51 util-linux-2.12q

 Follow sections 6.46 to 6.59 including the application of all patches
mentioned.  Note that perl should be upgraded to 5.8.7 and vim should
have the vim-6.3-security_fix-2.patch.


6.52 nasm - removed, it isn't needed (noted by John Miller).

6.53 bin86-0.16.17

 First apply patch bin86-x86_64.patch.
There is no configure, so

	make
	make install


6.54 lilo-22.6.1 [ You should probably use 22.7, I used this
old version to keep in sync with the other systems on my
development box ]

 Again, there is no configure.

	make
	make install



7. Finishing the build.
_______________________

 Follow chapters 7, 8, and 9 of the LFS book!

 Obviously, you will need to set up /etc/lilo.conf and run lilo.


8.LIST OF REQUIRED PATCHES for LFS
___________________________________

 With a bit of luck, these should all be in
http://www.kenmoffat.uklinux.net/patches -
most of them are also available from lfs patches. 

bash-3.0-avoid_WCONTINUED-1.patch (target, native)
bash-3.0-fixes-3.patch (native)
bin86-x86_64.patch (native)
coreutils-5.2.1-suppress_uptime_kill_su-1.patch (native)
expect-5.43.0-spawn-1.patch (temp-tools)
flex-2.5.31-debian_fixes-3.patch (target, native)
gcc-3.4.3-specs-pure64-1.patch (cross, target)
gcc-3.4.3-linkonce-1.patch (native)
gcc-3.4.3-no_fixincludes-1.patch (native)
gcc-3.4.3-fix_configure_for_target_native-1.patch (target)
gcc-3.4.4-cross_search_paths-1.patch (cross)
gcc-3.4.4-amd64_lib-1.patch (native)
glibc-2.3.4-fix_test-1.patch (native)
glibc-2.3.4-amd64_lib-2.patch (cross, native)
gzip-1.3.5-security_fixes-1.patch (native)
inetutils-1.4.2-kernel_headers-1.patch (native)
iproute2-2.6.11_050330-remove_db-1.patch (native)
mktemp-1.5-add_tempfile-2.patch (native)
perl-5.8.7-libc-1.patch (temp-tools)
readline-5.0-fixes-1.patch (native)
sysklogd-1.4.1-fixes-1.patch (native)
tar-1.15.1-sparse_fix-1.patch (target, native)
util-linux-2.12q-cramfs-1.patch (native)
vim-6.3-security_fix-2.patch (native)


More toolchain thoughts
_______________________

 I'm reasonably sure that the future of x86_64 is to put all the
64-bit libraries in /lib.  Unfortunately, the various toolchain
maintainers have gone for /lib64 in some places (makes sense for
transitional distros using 32-bit binaries linked against lib, I
suppose, and follows other 64-bit arches which may not want a
primarily 64-bit userspace).  This has a tendency to bite.

 I hope to get to play with lib and lib32, but until I've got that
building OK I can't say for certain if it will be a sensible way
to use 32-bit binaries.

 Users of recent nvidia (and perhaps ati) graphics cards who rely
on drivers from the manufacturer may be forced to use lib64.


9. BLFS.
________


 Because we are using lib for 64-bit libraries, there is very little
to comment on.


9.1 Packages that don't recognise x86_64

 Some packages haven't been altered for several years and predate the
introduction of x86_64.  The normal fix is to copy config.guess and
config.sub from /usr/share/automake-1.9.5/ into the current directory
before running ./configure.  Affected packages are:

9.1.1 a2ps-4.13b : exceptionally. copy them to auxdir/

9.1.2 glib-1.2.10

9.1.3 gtk+-1.2.10

9.1.4 jpegsrc.v6b

9.1.5 traceroute-1.4a12


9.2 Packages where the BLFS instructions have to be modified

9.2.0 gcc - see comments in native build of gcc above re bootstrap.

9.2.1 kdelibs-3.4.x

	In configure, --disable-fast-malloc [ --enable-fast-malloc is
	pnly supported on x86 ]

9.2.2 mpg123-pre0.59s

 This package is no longer maintained.  The BLFS book is stuck on
version 0.59r, but I use the last prerelease version of this, with
some gentoo security patches, because it works on ppc.

	make PREFIX=/usr linux-x86_64
	make PREFIX=/usr install


9.2.3 unzip552

 The BLFS instructions are for x86

	cp unix/Makefile .
	make prefix=/usr linux_noasm
	make prefix=/usr install


9.3 X.org

 X has an unhealthy desire to use lib64.  It's corrected by using the
following in host.def

	#define LibDirName lib
	#define LibDir /usr/X11R6/lib/X11
	#define HaveLib64 NO

 Somewhat bizzarrely, the HaveLib64 NO only affects the symlinks for
libGL.so in /usr. 


9.4 Packages that need fixing for -fPIC

 I find these a bit scary - if you don't add -fPIC, the error message
refers to x86_64_32.

9.4.1 a52dec-0.7.4

	./configure --prefix=/usr --enable-shared CFLAGS="$CFLAGS -fPIC"


9.4.2 espgs-7.07-1

	If you are installing ijs before you build the main package,
	 make CFLAGS="$CFLAGS -fPIC"
	in the ijs directory (ijs is needed for escputil from gutenprint)


9.4.3 ffmpeg-0.4.9-pre1

	make OPTCFLAGS=-fPIC


9.4.4 libmng-1.0.9

	sed -e 's%-O3%-O3 -fPIC%' makefile.linux >Makefile


9.5 Packages that need patches for x86_64

9.5.1 kdemultimedia-3.4.{0,1,2} need kdemultimedia-3.4.0-x86_64.patch-1
 Hmm, I thought the patch had come from upstream - somebody better give
the kde developers some 64-bit x86_64 machines so that they prioritise
this :)


ACKNOWLEDGEMENTS:
_________________

or, further references

cross-compiling:

 Dan Kegel	http://www.kegel.com/crosstool/

 Ryan's cross-lfs scripts

  http://www.linuxfromscratch.org/~ryan/scripts/cross-lfs/

 The Cross-LFS book, particularly Jim Gifford's contributions.  Subversion users can
download this from LFS as the cross-lfs branch.  For html, try 

  http://www.linuxfromscratch.org/~jhuntwork/cross-lfs
 or
  http://documents.jg555.com/cross-lfs/ 

other LFS on x86_64:

 Chris Lingard	http://www.stockwith.co.uk/x86_64/ (links are broken)

 Eric Johnson	http://home.ix.netcom.com/~ejohns/

 Theo Scheider	http://www.schneider-berlin.net/


CHANGELOG:
__________

2005-07-12	First version.

2005-08-01	First public release.

2005-08-02	minor updates to text.

2005-08-04	X.org really is corrected by the third additions,
		not 'mostly corrected'.

2005-08-16	Final version, some security updates per lfs errata,
		comments on glibc test/kernel possible interaction,
		corrected some of my numbering in chapter 6.  Tidied
		a few of the comments.

Updated versions of this hint may be found at
http://www.kenmoffat.uklinux.net/hints/