Generating a cross compiler

[Kai Ruottu]

11.10.2011 15:33, David Dudley kirjoitti:

> I bet this general subject comes up quite a bit.
>
> I need to generate a cross compiler that will run on my OSX Darwin computer,
> and generate objects for a i686-pc-linux-gnu system.
>
> I¹m building with 4.6.1 on a Mac Pro / Snow Leopard 10.6.8.
>
> The compiler builds fine till it gets to needing crti.o, crt1.o, libc.a, and
> libm.a.  I would have thought that pieces required for the compiler itself
> would have been built in the compiler.  I¹m using the include files from the
> target Linux system to build things (since it wouldn¹t get to this point
> without them.  If you¹re building a cross compiler to build the target
> system, what sense does it make to require files from the target, which
> might not exist yet?).

The "might not exist yet" should be a rare case, usually crosscompiling
is needed when one doesn't have the "native" target system available for
native compiling. For instance people would like to support your OSX
Darwin system although having only a PC with Ubuntu, Fedora, SuSE or
some other Linux. Or support the Sparc and x86 Solaris systems... Even
supporting some older version of the currently chosen native system,
like Fedora 8 on a brand new Fedora 14 development system would require
having a crosstoolchain for the older system.

Generally "building a cross compiler to build the target system" doesn't
fit to the as default "existing target" scheme, the goal really isn't
just a crosstoolchain for something existing but to create a totally
new system, so calling this goal as "creating a crosstoolchain" is very
misleading. My opinion is that the method with which the crosstoolchain
will be created shouldn't have much importance at all, it is just one
of the required tools in the process whose goal is that new system. But
in this process people tend to have weird "puritan" attitudes like never
accepting any "suitable" temporary components like a prebuilt glibc for
some "similar" target system. Producing GCC with libgcc, libstdc++ etc.
extra target libraries needs the base "standard C library" for the
target during the build.

In your case the expected "easy as a pie" process would be :

1. produce binutils for the target, nothing from the target system is
    required, use the '--with-sysroot=$sysroot' to tell where the target
    C library, root for 'lib', 'usr/include', 'usr/lib' etc., will be
    installed later

2. provide a temporary "suitable" target C library from some existing
    'i686-pc-linux-gnu' system, like Fedora 8 (it has glibc-2.5 I think).
    Put (unpack) it into the chosen suitable '$sysroot'. For instance
    '/opt/host-i686-pc-linux-gnu'. The base 'glibc-' and 'glibc-devel-'
    '.rpm's or '.deb's etc. with the kernel-headers package would be
    enough for the temporary target C library.

3. produce a complete GCC for the target, use the
    '--with-sysroot=$sysroot' to tell where the target C library is.

4. produce your own final glibc for the target. Installing it into the
    $sysroot will replace the temporary ("bootstrap") one there. The
    required command was 'make install_root=$sysroot install' or
    something. What is important is that one uses '--prefix=/usr' here
    when configuring glibc because the target C library will be built to
    work on the native target system, not on the cross host system -
    the resulted glibc, its runtime parts, is one part of the final
    target system!

The step 2 is the one causing vomiting in the "puritan" people, but
surprisingly not using a prebuilt native GCC, prebuilt native C library
or any other prebuilt native tools. But if the target system would
really be the example case Fedora 8/i686, then maybe not. The step 4
then causes the question: "What kind of GCC will work in building a
glibc?" Or: "Does a stripped GCC evem without a libgcc work?"

Of course every GCC builder is expected to know that the build commands
for a "naked GCC" :

make all-gcc
make install-gcc

would work for making "only a GCC, nothing else", and not require
anything from the target system. But making a "normal" GCC (for a
system target) will need these things always...

Generally this issue is fully equivalent to driving with "wrong tyres"
to a tyre shop or a smith using a pre-made hammer when producing a new,
originally unexisting hammer. The world is full of these equivalent
cases. The traditional puritan was the myriapod who was asked how it
solved the order of its steps during walking. After starting to think
that, it never walked again :(

> I¹m trying to build everything (binutils, gcc, gmp, mpfr, mpc) in a single
> pass which doesn¹t work with mpc as it fails if gmp and mpfr aren¹t already
> installed.

These will be a part of the cross host system, aimed to be built only
once and installed only once, after which one can produce tens of cross
tools which may require them at runtime...

   I¹m assuming that crti and the other libs I need are probably in
> glibc, so is there a way I can link it into my combined director to build as
> a part of the process?
>
> Later -
>
> David
>