LFS Toolchain

[Jeremy Huntwork]

Gerard Beekmans wrote:
> Can somebody do me a favour and give me both a high overview and a 
> detailed technical nitty-gritty overview of those three (are there 
> more?) methods - how they compare to each other.

You've summarized it pretty well. What is currently in trunk is based on 
current DIY, however, there are a few aspects that are not finished and 
it needs some attention, whatever is decided about actual direction. It 
is a new approach compared to earlier versions of LFS in that the the 
first pass of binutils and gcc we are creating cross compilers and the 
chapter 5 glibc is cross compiled. It is a native build from that point 
forward.

Some weeks ago, Ryan proposed a somewhat alternative method that does 
not require any adjustment of the toolchain in chapter 5 and does not 
depend on using -B/tools/lib/, by the cross compiler in order to get it 
to find the new startfiles. There is also a patch that DIY and current 
trunk uses for GCC pass 2 which reverts GCC to old functionality so that 
it will use prefix to find the startfiles. Ryan's approach also does not 
require the use of this patch.

After Ryan proposed his method, CLFS incorporated it into a native build 
approach and I also started looking at taking the core concepts directly 
from Ryan's email and adapting to LFS for testing purposes. This is what 
is currently found at:

http://www.linuxfromscratch.org/~jhuntwork/lfs-multilib/

This method uses sysroot functionality in GCC and Binutils to help 
'mask' off the host system further. IIUC, Greg's objection is that this 
is abusing what sysroot was intended for, Ryan's stance is that the 
intention of sysroot was more generic.

I like this method for the fact that gcc is configured right away to 
point at /tools and there's no post-install configuration/modification 
of GCC in order to get it to find its startfiles and headers in /tools. 
Greg says we're 'hacking the source' in the first pass of GCC, but if 
you actually look at the changes being done, it's the same modification 
of config/linux.h that the specs patch has always done in pass 2 to get 
gcc to use /tools.

Hope this helps.

--
JH