building 'native', 'cross' and 'cross-native' GCCs

[Michael Zintakis <michael dot zintakis at googlemail dot com>]

I've started posting on the main gcc mailing list and was referred to 
the crosstool-ng web site and this is how I found this mailing list.

For one of my projects I need to build a software bundle (installable 
ISO image) containing a mixture of free and propriety software (all 
compiled from source!). This software image needs to be installed/run on 
different architectures from the machine on which is built.

To start with, in 'phase 1' of this project I intend to build this image 
on x86_64 and serve 2 different target architectures: i586/i686 and 
powerpc. The target kernel is likely to be in two different Linux 
'flavours': LFS (Linux from scratch) and Fedora.

The way I look at it (based on what I read and was advised from various 
sources) I need to do the following steps in order to build the complete 
software image:

1. download GCC and other toolchain source tars (including target 
kernel+headers).

2. build GCC 1 perhaps following the 3-stage guide as described on the 
main GCC site (GCC1 is of type 'native' - following crosstool-ng 
terminology);

3. then use GCC 1 to build GCC 2 ('cross') and its corresponding 
toolchain which is for host x86_64 and target either powerpc or 
i586/i686 (depending on the scenario I would need either of these 
architectures, but not both, hence this is one compiler with different 
cross-tool chains depending on the need I have).

4. use GCC 2 to build GCC 3 ('native-cross') which would form part of 
the target software system allowing compilation of software for the 
target architecture only on the target architecture only. I am still 
unclear as to whether I need to (or should!) use the 3-stage or 
single-stage path for this compiler.

5. use GCC 2 to build the rest of the software and create the final 
image which is then deployed to the target machine(s).

GCC1 & GCC 2 and their subsequent toolchains would be 'temporary' and 
will be deleted before the final software image is assembled. Also, the 
way I see it steps 3, 4 and 5 will be in chrooted environment as by then 
I will have a good, tested GCC built.

My questions:

1. Would crosstool-ng be able to help me with the above, step 3 in 
particular (ideally step 4 as well)? I have spent the best part of last 
week bashing my head against it and could only muster compiling GCC1, 
build cross binutils and then the whole process comes to a screeching 
halt at the point where the fully-blown 'cross' GCC2 compilation is 
attempting to use glibc headers (from what I understand to build glibc I 
would need a bare-bone 'cross' gcc built - so a bit of a chicken-and-egg 
scenario). I attempted to use Dan Kegel's crosstool, but it is terribly 
outdated and for me to make it work I would need to spend some 
considerable time and I am not entirely sure I have the necessary 
expertise to do it (I'll probably blow a gasket, or two, before I reach 
that point :-) ).

2. If so, could crosstool-ng be integrated into my own build process 
above without causing major headaches?

3. If both 1 & 2 above are possible, then it comes my ideal scenario - 
building GCC 1, GCC2 and GCC3 in easy-to-follow steps using crosstool-ng 
(I am particularly fussy with regards to GCC1 as this compiler, once 
built, *must* be fully tested because everything from there on will be 
relying/built using that toolchain and there won't/shouldn't be any 
further reliance on the host system!).

Provided my project succeeds I may extend the target architectures to 
include other 'common' Linux platforms, but that is looking a bit too 
far into the future, for now I would need to be able to build x86_64 -> 
i586/i686 and x86_64 -> powerpc (G2 mainly).

One other point to note - all sources needed for the entire build 
process will be downloaded and placed in a separate directory prior to 
starting that build process. Once this is done, there shouldn't be any 
net access allowed from that point.

Is the above doable? Apologies if any of my queries are a bit 'daft' - 
this is my first attempt in facing that kind of difficulties.

--
For unsubscribe information see http://sourceware.org/lists.html#faq