docs/6 - Toolchain types.txt
author Bryan Hundven <bryanhundven@gmail.com>
Sun Jun 26 03:26:54 2011 -0700 (2011-06-26)
changeset 2515 364b06df9e3a
child 2563 e17f35b05539
permissions -rw-r--r--
glibc: Refactor startfiles/headers into do_libc_backend()

Refactor the contents of 'do_libc_start_files()' and 'do_libc()' into a
parameterized 'do_libc_backend()'. 'do_libc_start_files()' and 'do_libc()'
call 'do_libc_backend()' with either 'libc_mode=startfiles' or
'libc_mode=final' (respectively) so that the startfiles/headers and
the final libc builds are configured and built with the same options.

One example of where this is needed is when building a mips toolchain.
Previously, if you were building an n32 toolchain, you wouldn't have
noticed an issue, because if '-mabi' is not in CFLAGS, n32 is the
default:

http://sourceware.org/git/?p=glibc-ports.git;a=blob;f=sysdeps/mips/preconfigure;hb=HEAD

But when trying to build an o32 or n64 toolchain the build would
have failed. This is because (e)glibc expects "-mabi={o32,n32,n64}" to be
in CFLAGS, but was not previously provided in 'do_libc_start_files()'.
The build failure would happen in the shared-core gcc when it tries to
configure an n64 or o32 gcc with an n32 libc.

A simpler solution would have been to just add TARGET_CFLAGS to configure
in 'do_libc_start_files()', but this way makes configure and make
consistent for both steps.

Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
yann@2076
     1
File.........: 6 - Toolchain types.txt
yann@2076
     2
Copyrigth....: (C) 2010 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
yann@2076
     3
License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5
yann@2076
     4
yann@2076
     5
yann@2076
     6
Toolchain types  /
yann@2076
     7
________________/
yann@2076
     8
yann@2076
     9
yann@2076
    10
There are four kinds of toolchains you could encounter.
yann@2076
    11
yann@2076
    12
First off, you must understand the following: when it comes to compilers there
yann@2076
    13
are up to four machines involved:
yann@2076
    14
  1) the machine configuring the toolchain components: the config machine
yann@2076
    15
  2) the machine building the toolchain components:    the build machine
yann@2076
    16
  3) the machine running the toolchain:                the host machine
yann@2076
    17
  4) the machine the toolchain is generating code for: the target machine
yann@2076
    18
yann@2076
    19
We can most of the time assume that the config machine and the build machine
yann@2076
    20
are the same. Most of the time, this will be true. The only time it isn't
yann@2076
    21
is if you're using distributed compilation (such as distcc). Let's forget
yann@2076
    22
this for the sake of simplicity.
yann@2076
    23
yann@2076
    24
So we're left with three machines:
yann@2076
    25
 - build
yann@2076
    26
 - host
yann@2076
    27
 - target
yann@2076
    28
yann@2076
    29
Any toolchain will involve those three machines. You can be as pretty sure of
yann@2076
    30
this as "2 and 2 are 4". Here is how they come into play:
yann@2076
    31
yann@2076
    32
1) build == host == target
yann@2076
    33
    This is a plain native toolchain, targetting the exact same machine as the
yann@2076
    34
    one it is built on, and running again on this exact same machine. You have
yann@2076
    35
    to build such a toolchain when you want to use an updated component, such
yann@2076
    36
    as a newer gcc for example.
yann@2076
    37
    crosstool-NG calls it "native".
yann@2076
    38
yann@2076
    39
2) build == host != target
yann@2076
    40
    This is a classic cross-toolchain, which is expected to be run on the same
yann@2076
    41
    machine it is compiled on, and generate code to run on a second machine,
yann@2076
    42
    the target.
yann@2076
    43
    crosstool-NG calls it "cross".
yann@2076
    44
yann@2076
    45
3) build != host == target
yann@2076
    46
    Such a toolchain is also a native toolchain, as it targets the same machine
yann@2076
    47
    as it runs on. But it is build on another machine. You want such a
yann@2076
    48
    toolchain when porting to a new architecture, or if the build machine is
yann@2076
    49
    much faster than the host machine.
yann@2076
    50
    crosstool-NG calls it "cross-native".
yann@2076
    51
yann@2076
    52
4) build != host != target
yann@2076
    53
    This one is called a canadian-toolchain (*), and is tricky. The three
yann@2076
    54
    machines in play are different. You might want such a toolchain if you
yann@2076
    55
    have a fast build machine, but the users will use it on another machine,
yann@2076
    56
    and will produce code to run on a third machine.
yann@2076
    57
    crosstool-NG calls it "canadian".
yann@2076
    58
yann@2076
    59
crosstool-NG can build all these kinds of toolchains (or is aiming at it,
yann@2076
    60
anyway!)
yann@2076
    61
yann@2076
    62
(*) The term Canadian Cross came about because at the time that these issues
yann@2076
    63
    were all being hashed out, Canada had three national political parties.
yann@2076
    64
    http://en.wikipedia.org/wiki/Cross_compiler