Wednesday 17 July 2013

LFS - Configuring tool chain

Continuing on building my LFS virtual image.

I am using version 7.3 of the LFS documentation, they have helpfully provided a file to use with wget to download all required packages and a separate md5sum list to verify once they have downloaded.

Files have all been downloaded to directory sources on my new filesystem (created in http://paulsrandomcontent.blogspot.co.uk/2013/07/lfs-creating-disk-image.html).

A new directory (tools) for tools has also been created and a symlink /tools has been created pointing to this location, e.g.

ln -sv /mnt/LFS/tools /

Instructions suggest the creation of a new non-root user for building packages so as not to damage the host system, which is a very good idea. I also want to keep this separate from my normal user on my system just in case.

I have created the user lfs to work with.

The following is also suggested to remove stray settings from our build host and create a simple bash_profile
cat > ~/.bash_profile << "EOF"
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
EOF



and the following to create a simple bashrc (note the mount location of the new filesystem for $LFS)

cat > ~/.bashrc << "EOF"
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
LFS_TGT=$(uname -m)-lfs-linux-gnu
PATH=/tools/bin:/bin:/usr/bin
export LFS LC_ALL LFS_TGT PATH
EOF


First step is to build our host independent toolchain which will be used for building tools needed to build our new system, these will be installed under $LFS/tools on our new filesystem.

While building binutils for a 64bit system it is recommended to create a 64bit lib location (which will be used by other tools as well) using the following

case $(uname -m) in
x86_64) mkdir -v /tools/lib && ln -sv lib /tools/lib64 ;;
esac


The list below marks the order in which the software packages were installed, however it should be noted that certain critical packages are install a couple of times to build a known good set of tools on our filesystem, which we use to build other software.

Binutils is required by both gcc and glibc configuration so must be built first. Once gcc is built it is used to build glibc. This new glibc can be used when rebuilding binutils and gcc, these tools will then be referencing only our new filesystem and not the host system. Effectively we are bootstrapping our compiler.


Tools built in the following order
binutils
gcc (only C language support)
Linux API headers (from kernel source, so glibc can interface with features provided by Linux kernel)
glibc

tcl (for binutils, gcc and other test suites)
expect
dejagnu
check
ncurses
bash
bzip2
coreutils
diffutils
file
findutils
gawk
msg-fmt binary (from gettext package)
grep
gzip
m4
make
patch
perl5 (only some tools and libraries for now)
sed
tar
texinfo
xz