|
0
|
1 @c Copyright (C) 2001, 2002, 2004, 2008 Free Software Foundation, Inc.
|
|
|
2 @c This is part of the GCC manual.
|
|
|
3 @c For copying conditions, see the file gcc.texi.
|
|
|
4
|
|
|
5 @node Configure Terms
|
|
|
6 @section Configure Terms and History
|
|
|
7 @cindex configure terms
|
|
|
8 @cindex canadian
|
|
|
9
|
|
|
10 The configure and build process has a long and colorful history, and can
|
|
|
11 be confusing to anyone who doesn't know why things are the way they are.
|
|
|
12 While there are other documents which describe the configuration process
|
|
|
13 in detail, here are a few things that everyone working on GCC should
|
|
|
14 know.
|
|
|
15
|
|
|
16 There are three system names that the build knows about: the machine you
|
|
|
17 are building on (@dfn{build}), the machine that you are building for
|
|
|
18 (@dfn{host}), and the machine that GCC will produce code for
|
|
|
19 (@dfn{target}). When you configure GCC, you specify these with
|
|
|
20 @option{--build=}, @option{--host=}, and @option{--target=}.
|
|
|
21
|
|
|
22 Specifying the host without specifying the build should be avoided, as
|
|
|
23 @command{configure} may (and once did) assume that the host you specify
|
|
|
24 is also the build, which may not be true.
|
|
|
25
|
|
|
26 If build, host, and target are all the same, this is called a
|
|
|
27 @dfn{native}. If build and host are the same but target is different,
|
|
|
28 this is called a @dfn{cross}. If build, host, and target are all
|
|
|
29 different this is called a @dfn{canadian} (for obscure reasons dealing
|
|
|
30 with Canada's political party and the background of the person working
|
|
|
31 on the build at that time). If host and target are the same, but build
|
|
|
32 is different, you are using a cross-compiler to build a native for a
|
|
|
33 different system. Some people call this a @dfn{host-x-host},
|
|
|
34 @dfn{crossed native}, or @dfn{cross-built native}. If build and target
|
|
|
35 are the same, but host is different, you are using a cross compiler to
|
|
|
36 build a cross compiler that produces code for the machine you're
|
|
|
37 building on. This is rare, so there is no common way of describing it.
|
|
|
38 There is a proposal to call this a @dfn{crossback}.
|
|
|
39
|
|
|
40 If build and host are the same, the GCC you are building will also be
|
|
|
41 used to build the target libraries (like @code{libstdc++}). If build and host
|
|
|
42 are different, you must have already built and installed a cross
|
|
|
43 compiler that will be used to build the target libraries (if you
|
|
|
44 configured with @option{--target=foo-bar}, this compiler will be called
|
|
|
45 @command{foo-bar-gcc}).
|
|
|
46
|
|
|
47 In the case of target libraries, the machine you're building for is the
|
|
|
48 machine you specified with @option{--target}. So, build is the machine
|
|
|
49 you're building on (no change there), host is the machine you're
|
|
|
50 building for (the target libraries are built for the target, so host is
|
|
|
51 the target you specified), and target doesn't apply (because you're not
|
|
|
52 building a compiler, you're building libraries). The configure/make
|
|
|
53 process will adjust these variables as needed. It also sets
|
|
|
54 @code{$with_cross_host} to the original @option{--host} value in case you
|
|
|
55 need it.
|
|
|
56
|
|
|
57 The @code{libiberty} support library is built up to three times: once
|
|
|
58 for the host, once for the target (even if they are the same), and once
|
|
|
59 for the build if build and host are different. This allows it to be
|
|
|
60 used by all programs which are generated in the course of the build
|
|
|
61 process.
|
