Building a cross-compiler

[Kai Ruottu]

Michael Witten wrote:

> Creating a cross compiler _should_ be the easiest
> thing in the world, but the gcc is so backasswards
> that it can be troublesome.
Most problems really come from the total ignorance about what GCC
is and what it isn't :(   A "C compiler" usually includes a "C library" and
all the required "binutils" like 'as' (assembler) and 'ld' (linker). GCC 
then
is a "bare compiler" which only produces assembly (symbolic machine
code) text...  So a GCC builder MUST provide both the binutils and the
C library BEFORE starting to build a GCC !

People building native GCCs don't need to care about these things, of
course there are those prebuilt binutils for instance in '/usr/bin' and 
a prebuilt
C library in '/lib', '/usr/lib' and '/usr/include', in the Linux case.  
So those
required "target binutils and target C library" are already there....  
We should
always remember that the "native GCC" is the DEFAULT GCC type and
the cross GCC is only "another incarnation of the native GCC" on some
other host!  And therefore all the same prerequisites will exist...

So many cross GCC builders have really weird opinions about what the GCC
build should require and what it shouldn't, totally forgetting that 
"native" default :(

Producing a cross GCC then is just as easy as producing a native one when
one hasn't any weird "attitude problems". One accepts those prerequisites
for the binutils and the C library and the build is easy as a pie...  
This of course
is true only with  "existing"  targets.  In the Linux target cases  all 
the Linux
distros are "existing".  Some with that attitude problem always claim 
that they
don't exist or that people shouldn't care or should be prepared to the doom
day when all those prebuilt Linux binaries have been destroyed :)

When one wants to make one's own Linux distro "from scratch", there are
many choices to do that crosstoolchain with which to produce the self-built
Linux distro.

The easiest way is to bootstrap with something "existing". Making the target
binutils is easy and doesn't require anything else than the host GCC 
(with its
own binutils and C library). But producing GCC is problematic, a "Catch 22"
or "Chicken and egg", because the target C library is missing :(  The 
produced
GCC will produce it but when producing GCC requires the target C library
during its build, what on earth to do?

Fortunately the world is full of similar cases...  A car builder may 
accept using
"wrong but suitable tyres" when driving to the tyre shop for those 
"right" tyres.
Driving with bare wheels isn't a sane alternative...  In cross GCC world 
this
means for instance that a glibc for Linux/MIPS is "suitable" when 
producing a
GCC for a "self-made" Linux/MIPS distro... Or a Linux/MIPSEL one.  One
place where to find it is  a Debian Linux archive, both 'mips' and 
'mipsel' targets
are supported...

When one uses some existing C library during the "first" GCC build, one 
learns
the "normal GCC build", used with existing targets and when updating the 
GCC.

Much harder is to try to start from absolute scratch...  The sadly 
famous "crosstool"
tries to help the people with the attitude problems.  When using it 
people will never
learn how others will build their own crosstoolchains in less time than 
one hour :(
Even with old < 1 GHz PCs....  When always starting from absolute 
scratch again,
the productivity is horribly low!


>>> Last time I did it, I found I had to have the binutils --prefix 
>>> directory
>>> the same --prefix as the compiler.
This is the assumption!  A cross GCC must use its own 'as' and 'ld', 
with their bare
names, from somewhere else than the native GCC!  It is not a "human 
user" for
whom those '$target-<tool>'s are aimed :(   Both the native and a cross 
GCC will
try to launch 'as' and 'ld' from their own built-in search directories 
seen with the
well-known (even for newbies) :

     $target-gcc -print-search-dirs

Every newbie of course can ask on-line help :

     $target-gcc --help

from the GCC if not remembering those most usual options... Or can RTFM....

Ok, the '$tooldir/bin' aka '$prefix/$target/bin' is the place where 
those target binutils
will be installed.  There are many $gcc-version specific search places 
for GCC version
specific 'as' and 'ld' if these are required to work-around something. 
People can have
installed many GCC versions for one $target, these generally using the 
same binutils
and the same C library. Having many native GCCs isn't rare, neither 
having many cross
GCCs for one target.

All the previous was for those "true" cross GCCs, for the "system 
targets" which also
have native GCCs for them...  The method for a GCC build for an 
"embedded target",
one which doesn't have any "native GCC" ever, then is totally different 
case !

Using the 'newlib' free C library is the assumption for all those 
"unreal" targets  like the
"elves".  Some claim that they have seen an 'elf' or an 'angel' (the 
default target for 'arm-elf'),
or that 'p(oke)mon' for the 'mips-elf', used to be patched as the 
default target in the GCC's
'specs' file.  But I haven't seen either :(   I have seen Linuces, 
Unices and such "real" targets
however...  The question is where on earth those executables will run?  
If one doesn't ask
this question, then those "basic courses about computers" have failed 
miserably...

Producing a GCC for a newlib-using target basically requires only :

1. the target binutils
2..the generic newlib headers
3. using the '--with-newlib' in the GCC configure

The prerequisites 1. and 2. means these being preinstalled, the 2. a 
single 'cp -r' command
made for the proper 'newlib/libc/include' in the sources....  After that 
everything belonging
to the C/C++ compilers should be produced!  There are very old and weird 
bugs hurting
this but then these things have been discussed tens or hundreds or 
thousands times... Like
that "sys-include bug".  Just use Google and all these discussions will 
be found!