Mercurial > hg > CbC > CbC_gcc
comparison gcc/doc/configterms.texi @ 0:a06113de4d67
first commit
author | kent <kent@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Fri, 17 Jul 2009 14:47:48 +0900 |
parents | |
children | 04ced10e8804 |
comparison
equal
deleted
inserted
replaced
-1:000000000000 | 0:a06113de4d67 |
---|---|
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. |