yann@2076
|
1 |
File.........: 6 - Toolchain types.txt
|
antony@2563
|
2 |
Copyright....: (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
|
antony@2564
|
33 |
This is a plain native toolchain, targeting 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
|