This is the mail archive of the
crossgcc@sourceware.org
mailing list for the crossgcc project.
See the CrossGCC FAQ for lots
more information.
building 'native', 'cross' and 'cross-native' GCCs
- From: Michael Zintakis <michael dot zintakis at googlemail dot com>
- To: crossgcc at sourceware dot org
- Date: Tue, 15 Mar 2011 13:38:15 +0000
- Subject: building 'native', 'cross' and 'cross-native' GCCs
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