![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-5 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Apple XNU] / GNUtools / cc|
Return to gcc.info-5 CVS log | Up to [Apple XNU] / GNUtools / cc |
1.1 root 1: This is Info file gcc.info, produced by Makeinfo-1.54 from the input
2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
6: Published by the Free Software Foundation 675 Massachusetts Avenue
7: Cambridge, MA 02139 USA
8:
9: Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
10:
11: Permission is granted to make and distribute verbatim copies of this
12: manual provided the copyright notice and this permission notice are
13: preserved on all copies.
14:
15: Permission is granted to copy and distribute modified versions of
16: this manual under the conditions for verbatim copying, provided also
17: that the sections entitled "GNU General Public License" and "Protect
18: Your Freedom--Fight `Look And Feel'" are included exactly as in the
19: original, and provided that the entire resulting derived work is
20: distributed under the terms of a permission notice identical to this
21: one.
22:
23: Permission is granted to copy and distribute translations of this
24: manual into another language, under the above conditions for modified
25: versions, except that the sections entitled "GNU General Public
26: License" and "Protect Your Freedom--Fight `Look And Feel'", and this
27: permission notice, may be included in translations approved by the Free
28: Software Foundation instead of in the original English.
29:
30:
31: File: gcc.info, Node: Installation, Next: C Extensions, Prev: Invoking GCC, Up: Top
32:
33: Installing GNU CC
34: *****************
35:
36: Here is the procedure for installing GNU CC on a Unix system.
37:
38: * Menu:
39:
40: * Other Dir:: Compiling in a separate directory (not where the source is).
41: * Cross-Compiler:: Building and installing a cross-compiler.
42: * PA Install:: See below for installation on the HP Precision Architecture.
43: * Sun Install:: See below for installation on the Sun.
44: * 3b1 Install:: See below for installation on the 3b1.
45: * Unos Install:: See below for installation on Unos (from CRDS).
46: * VMS Install:: See below for installation on VMS.
47: * WE32K Install:: See below for installation on the 3b* aside from the 3b1.
48: * MIPS Install:: See below for installation on the MIPS Architecture.
49: * Collect2:: How `collect2' works; how it finds `ld'.
50: * Header Dirs:: Understanding the standard header file directories.
51:
52: 1. If you have built GNU CC previously in the same directory for a
53: different target machine, do `make distclean' to delete all files
54: that might be invalid. One of the files this deletes is
55: `Makefile'; if `make distclean' complains that `Makefile' does not
56: exist, it probably means that the directory is already suitably
57: clean.
58:
59: 2. On a System V release 4 system, make sure `/usr/bin' precedes
60: `/usr/ucb' in `PATH'. The `cc' command in `/usr/ucb' uses
61: libraries which have bugs.
62:
63: 3. Specify the host and target machine configurations. You do this by
64: running the file `configure' with appropriate arguments.
65:
66: If you are building a compiler to produce code for the machine it
67: runs on, specify just one machine type, with the `--target'
68: option; the host type will default to be the same as the target.
69: (For information on building a cross-compiler, see *Note
70: Cross-Compiler::.) Here is an example:
71:
72: configure --target=sparc-sun-sunos4.1
73:
74: If you run `configure' without specifying configuration arguments,
75: `configure' tries to guess the type of host you are on, and uses
76: that configuration type for both host and target. So you don't
77: need to specify a configuration, for building a native compiler,
78: unless `configure' cannot figure out what your configuration is.
79:
80: A configuration name may be canonical or it may be more or less
81: abbreviated.
82:
83: A canonical configuration name has three parts, separated by
84: dashes. It looks like this: `CPU-COMPANY-SYSTEM'. (The three
85: parts may themselves contain dashes; `configure' can figure out
86: which dashes serve which purpose.) For example,
87: `m68k-sun-sunos4.1' specifies a Sun 3.
88:
89: You can also replace parts of the configuration by nicknames or
90: aliases. For example, `sun3' stands for `m68k-sun', so
91: `sun3-sunos4.1' is another way to specify a Sun 3. You can also
92: use simply `sun3-sunos', since the version of SunOS is assumed by
93: default to be version 4. `sun3-bsd' also works, since `configure'
94: knows that the only BSD variant on a Sun 3 is SunOS.
95:
96: You can specify a version number after any of the system types,
97: and some of the CPU types. In most cases, the version is
98: irrelevant, and will be ignored. So you might as well specify the
99: version if you know it.
100:
101: Here are the possible CPU types:
102:
103: a29k, alpha, arm, cN, clipper, elxsi, h8300, hppa1.0, hppa1.1,
104: i370, i386, i486, i860, i960, m68000, m68k, m88k, mips,
105: ns32k, pyramid, romp, rs6000, sh, sparc, sparclite, vax,
106: we32k.
107:
108: Here are the recognized company names. As you can see, customary
109: abbreviations are used rather than the longer official names.
110:
111: alliant, altos, apollo, att, bull, cbm, convergent, convex,
112: crds, dec, dg, dolphin, elxsi, encore, harris, hitachi, hp,
113: ibm, intergraph, isi, mips, motorola, ncr, next, ns, omron,
114: plexus, sequent, sgi, sony, sun, tti, unicom.
115:
116: The company name is meaningful only to disambiguate when the rest
117: of the information supplied is insufficient. You can omit it,
118: writing just `CPU-SYSTEM', if it is not needed. For example,
119: `vax-ultrix4.2' is equivalent to `vax-dec-ultrix4.2'.
120:
121: Here is a list of system types:
122:
123: aix, acis, aos, bsd, clix, ctix, dgux, dynix, genix, hpux,
124: isc, linux, luna, lynxos, mach, minix, newsos, osf, osfrose,
125: riscos, sco, solaris, sunos, sysv, ultrix, unos, vms.
126:
127: You can omit the system type; then `configure' guesses the
128: operating system from the CPU and company.
129:
130: You can add a version number to the system type; this may or may
131: not make a difference. For example, you can write `bsd4.3' or
132: `bsd4.4' to distinguish versions of BSD. In practice, the version
133: number is most needed for `sysv3' and `sysv4', which are often
134: treated differently.
135:
136: If you specify an impossible combination such as `i860-dg-vms',
137: then you may get an error message from `configure', or it may
138: ignore part of the information and do the best it can with the
139: rest. `configure' always prints the canonical name for the
140: alternative that it used.
141:
142: Often a particular model of machine has a name. Many machine
143: names are recognized as aliases for CPU/company combinations.
144: Thus, the machine name `sun3', mentioned above, is an alias for
145: `m68k-sun'. Sometimes we accept a company name as a machine name,
146: when the name is popularly used for a particular machine. Here is
147: a table of the known machine names:
148:
149: 3300, 3b1, 3bN, 7300, altos3068, altos, apollo68, att-7300,
150: balance, convex-cN, crds, decstation-3100, decstation, delta,
151: encore, fx2800, gmicro, hp7NN, hp8NN, hp9k2NN, hp9k3NN,
152: hp9k7NN, hp9k8NN, iris4d, iris, isi68, m3230, magnum, merlin,
153: miniframe, mmax, news-3600, news800, news, next, pbd, pc532,
154: pmax, ps2, risc-news, rtpc, sun2, sun386i, sun386, sun3,
155: sun4, symmetry, tower-32, tower.
156:
157: Remember that a machine name specifies both the cpu type and the
158: company name.
159:
160: There are four additional options you can specify independently to
161: describe variant hardware and software configurations. These are
162: `--with-gnu-as', `--with-gnu-ld', `--with-stabs' and `--nfp'.
163:
164: `--with-gnu-as'
165: If you will use GNU CC with the GNU assembler (GAS), you
166: should declare this by using the `--with-gnu-as' option when
167: you run `configure'.
168:
169: Using this option does not install GAS. It only modifies the
170: output of GNU CC to work with GAS. Building and installing
171: GAS is up to you.
172:
173: The systems where it makes a difference whether you use GAS
174: are `hppa1.0-ANYTHING-ANYTHING', `hppa1.1-ANYTHING-ANYTHING',
175: `i386-ANYTHING-sysv', `i860-ANYTHING-bsd', `m68k-bull-sysv',
176: `m68k-hp-hpux', `m68k-sony-bsd', `m68k-altos-sysv',
177: `m68000-hp-hpux', `m68000-att-sysv', and `mips-ANY'). On any
178: other system, `--with-gnu-as' has no effect.
179:
180: On the systems listed above (except for the HP-PA), if you
181: use GAS, you should also use the GNU linker (and specify
182: `--with-gnu-ld').
183:
184: `--with-gnu-ld'
185: Specify the option `--with-gnu-ld' if you plan to use the GNU
186: linker with GNU CC.
187:
188: This option does not cause the GNU linker to be installed; it
189: just modifies the behavior of GNU CC to work with the GNU
190: linker. Specifically, it inhibits the installation of
191: `collect2', a program which otherwise serves as a front-end
192: for the system's linker on most configurations.
193:
194: `--with-stabs'
195: On MIPS based systems and on Alphas, you must specify whether
196: you want GNU CC to create the normal ECOFF debugging format,
197: or to use BSD-style stabs passed through the ECOFF symbol
198: table. The normal ECOFF debug format cannot fully handle
199: languages other than C. BSD stabs format can handle other
200: languages, but it only works with the GNU debugger GDB.
201:
202: Normally, GNU CC uses the ECOFF debugging format by default;
203: if you prefer BSD stabs, specify `--with-stabs' when you
204: configure GNU CC.
205:
206: No matter which default you choose when you configure GNU CC,
207: the user can use the `-gcoff' and `-gstabs+' options to
208: specify explicitly the debug format for a particular
209: compilation.
210:
211: `--nfp'
212: On certain systems, you must specify whether the machine has
213: a floating point unit. These systems include
214: `m68k-sun-sunosN' and `m68k-isi-bsd'. On any other system,
215: `--nfp' currently has no effect, though perhaps there are
216: other systems where it could usefully make a difference.
217:
218: If you want to install your own homemade configuration files, you
219: can use `local' as the company name to access them. If you use
220: configuration `CPU-local', the configuration name without the cpu
221: prefix is used to form the configuration file names.
222:
223: Thus, if you specify `m68k-local', configuration uses files
224: `local.md', `local.h', `local.c', `xm-local.h', `t-local', and
225: `x-local', all in the directory `config/m68k'.
226:
227: Here is a list of configurations that have special treatment or
228: special things you must know:
229:
230: `alpha-*-osf1'
231: Systems using processors that implement the DEC Alpha
232: architecture and are running the OSF/1 operating system, for
233: example the DEC Alpha AXP systems. (VMS on the Alpha is not
234: currently supported by GNU CC.)
235:
236: GNU CC writes a `.verstamp' directive to the assembler output
237: file unless it is built as a cross-compiler. It gets the
238: version to use from the system header file
239: `/usr/include/stamp.h'. If you install a new version of
240: OSF/1, you should rebuild GCC to pick up the new version
241: stamp.
242:
243: Note that since the Alpha is a 64-bit architecture,
244: cross-compilers from 32-bit machines will not generate as
245: efficient code as that generated when the compiler is running
246: on a 64-bit machine because many optimizations that depend on
247: being able to represent a word on the target in an integral
248: value on the host cannot be performed. Building
249: cross-compilers on the Alpha for 32-bit machines has only
250: been tested in a few cases and may not work properly.
251:
252: `make compare' may fail on some versions of OSF/1 unless you
253: add `-save-temps' to `BOOT_CFLAGS'. This forces a fixed name
254: to be used for the assembler input file instead of a random
255: name in `/tmp'. The name of the assembler input file is
256: stored in the object file and will cause miscompared if it
257: differs between the `stage1' and `stage2' compilations.
258:
259: GNU CC now supports both the native (ECOFF) debugging format
260: used by DBX and GDB and an encapsulated STABS format for use
261: only with GDB. See the discussion of the `--with-stabs'
262: option of `configure' above for more information on these
263: formats and how to select them.
264:
265: There is a bug in DEC's assembler that produces incorrect
266: line numbers for ECOFF format when the `.align' directive is
267: used. To work around this problem, GNU CC will not emit such
268: alignment directives even if optimization is being performed
269: if it is writing ECOFF format debugging information.
270: Unfortunately, this has the very undesirable side-effect that
271: code addresses when `-O' is specified are different depending
272: on whether or not `-g' is also specified.
273:
274: To avoid this behavior, specify `-gstabs+' and use GDB
275: instead of DBX. DEC is now aware of this problem with the
276: assembler and hopes to provide a fix shortly.
277:
278: `a29k'
279: AMD Am29k-family processors. These are normally used in
280: embedded applications. There are no standard Unix
281: configurations. This configuration corresponds to AMD's
282: standard calling sequence and binary interface and is
283: compatible with other 29k tools.
284:
285: You may need to make a variant of the file `a29k.h' for your
286: particular configuration.
287:
288: `a29k-*-bsd'
289: AMD Am29050 used in a system running a variant of BSD Unix.
290:
291: `elxsi-elxsi-bsd'
292: The Elxsi's C compiler has known limitations that prevent it
293: from compiling GNU C. Please contact `[email protected]' for
294: more details.
295:
296: `hppa*-*-*'
297: Using GAS is highly recommended for all HP-PA configurations.
298: See *Note PA Install:: for the special procedures needed to
299: compile GNU CC for the HP-PA.
300:
301: `i386-*-sco'
302: Compilation with RCC is recommended. Also, it may be a good
303: idea to link with GNU malloc instead of the malloc that comes
304: with the system.
305:
306: `i386-*-sco3.2.4'
307: Use this configuration for SCO release 3.2 version 4.
308:
309: `i386-*-isc'
310: It may be good idea to link with GNU malloc instead of the
311: malloc that comes with the system.
312:
313: `i386-*-esix'
314: It may be good idea to link with GNU malloc instead of the
315: malloc that comes with the system.
316:
317: `i386-ibm-aix'
318: You need to use GAS version 2.1 or later, and and LD from GNU
319: binutils version 2.2 or later.
320:
321: `i386-sequent'
322: Go to the Berkeley universe before compiling. In addition,
323: you probably need to create a file named `string.h'
324: containing just one line: `#include <strings.h>'.
325:
326: `i386-sun-sunos4'
327: You may find that you need another version of GNU CC to begin
328: bootstrapping with, since the current version when built with
329: the system's own compiler seems to get an infinite loop
330: compiling part of `libgcc2.c'. GNU CC version 2 compiled
331: with GNU CC (any version) seems not to have this problem.
332:
333: `m68000-att'
334: AT&T 3b1, a.k.a. 7300 PC. Special procedures are needed to
335: compile GNU CC with this machine's standard C compiler, due
336: to bugs in that compiler. *Note 3b1 Install::. You can
337: bootstrap it more easily with previous versions of GNU CC if
338: you have them.
339:
340: `m68000-hp-bsd'
341: HP 9000 series 200 running BSD. Note that the C compiler
342: that comes with this system cannot compile GNU CC; contact
343: `[email protected]' to get binaries of GNU CC for bootstrapping.
344:
345: `m68k-altos'
346: Altos 3068. You must use the GNU assembler, linker and
347: debugger. Also, you must fix a kernel bug. Details in the
348: file `README.ALTOS'.
349:
350: `m68k-bull-sysv'
351: Bull DPX/2 series 200 and 300 with BOS-2.00.45 up to
352: BOS-2.01. GNU CC works either with native assembler or GNU
353: assembler. You can use GNU assembler with native coff
354: generation by providing `--gas' to the configure script or
355: use GNU assembler with dbx-in-coff encapsulation by providing
356: `--gas --stabs'. For any problem with native assembler or for
357: availability of the DPX/2 port of GAS, contact
358: `[email protected]'.
359:
360: `m68k-hp-hpux'
361: HP 9000 series 300 or 400 running HP-UX. HP-UX version 8.0
362: has a bug in the assembler that prevents compilation of GNU
363: CC. To fix it, get patch PHCO_0800 from HP.
364:
365: In addition, `--gas' does not currently work with this
366: configuration. Changes in HP-UX have broken the library
367: conversion tool and the linker.
368:
369: `m68k-sun'
370: Sun 3. We do not provide a configuration file to use the Sun
371: FPA by default, because programs that establish signal
372: handlers for floating point traps inherently cannot work with
373: the FPA.
374:
375: `m88k-*-svr3'
376: Motorola m88k running the AT&T/Unisoft/Motorola V.3 reference
377: port. These systems tend to use the Green Hills C, revision
378: 1.8.5, as the standard C compiler. There are apparently bugs
379: in this compiler that result in object files differences
380: between stage 2 and stage 3. If this happens, make the stage
381: 4 compiler and compare it to the stage 3 compiler. If the
382: stage 3 and stage 4 object files are identical, this suggests
383: you encountered a problem with the standard C compiler; the
384: stage 3 and 4 compilers may be usable.
385:
386: It is best, however, to use an older version of GNU CC for
387: bootstrapping if you have one.
388:
389: `m88k-*-dgux'
390: Motorola m88k running DG/UX. To build native or cross
391: compilers on DG/UX, you must first change to the 88open BCS
392: software development environment. This is done by issuing
393: this command:
394:
395: eval `sde-target m88kbcs`
396:
397: `m88k-tektronix-sysv3'
398: Tektronix XD88 running UTekV 3.2e. Do not turn on
399: optimization while building stage1 if you bootstrap with the
400: buggy Green Hills compiler. Also, The bundled LAI System V
401: NFS is buggy so if you build in an NFS mounted directory,
402: start from a fresh reboot, or avoid NFS all together.
403: Otherwise you may have trouble getting clean comparisons
404: between stages.
405:
406: `mips-mips-bsd'
407: MIPS machines running the MIPS operating system in BSD mode.
408: It's possible that some old versions of the system lack the
409: functions `memcpy', `memcmp', and `memset'. If your system
410: lacks these, you must remove or undo the definition of
411: `TARGET_MEM_FUNCTIONS' in `mips-bsd.h'.
412:
413: `mips-sgi-*'
414: Silicon Graphics MIPS machines running IRIX. In order to
415: compile GCC on an SGI the "c.hdr.lib" option must be
416: installed from the CD-ROM supplied from Silicon Graphics.
417: This is found on the 2nd CD in release 4.0.1.
418:
419: `mips-sony-sysv'
420: Sony MIPS NEWS. This works in NEWSOS 5.0.1, but not in 5.0.2
421: (which uses ELF instead of COFF). Support for 5.0.2 will
422: probably be provided soon by volunteers. In particular, the
423: linker does not like the code generated by GCC when shared
424: libraries are linked in.
425:
426: `ns32k-encore'
427: Encore ns32000 system. Encore systems are supported only
428: under BSD.
429:
430: `ns32k-*-genix'
431: National Semiconductor ns32000 system. Genix has bugs in
432: `alloca' and `malloc'; you must get the compiled versions of
433: these from GNU Emacs.
434:
435: `ns32k-sequent'
436: Go to the Berkeley universe before compiling. In addition,
437: you probably need to create a file named `string.h'
438: containing just one line: `#include <strings.h>'.
439:
440: `ns32k-utek'
441: UTEK ns32000 system ("merlin"). The C compiler that comes
442: with this system cannot compile GNU CC; contact
443: `tektronix!reed!mason' to get binaries of GNU CC for
444: bootstrapping.
445:
446: `romp-*-aos'
447: `romp-*-mach'
448: The only operating systems supported for the IBM RT PC are
449: AOS and MACH. GNU CC does not support AIX running on the RT.
450: We recommend you compile GNU CC with an earlier version of
451: itself; if you compile GNU CC with `hc', the Metaware
452: compiler, it will work, but you will get mismatches between
453: the stage 2 and stage 3 compilers in various files. These
454: errors are minor differences in some floating-point constants
455: and can be safely ignored; the stage 3 compiler is correct.
456:
457: `rs6000-*-aix'
458: *Read the file `README.RS6000' for information on how to get
459: a fix for problems in the IBM assembler that interfere with
460: GNU CC.* You must either obtain the new assembler or avoid
461: using the `-g' switch. Note that `Makefile.in' uses `-g' by
462: default when compiling `libgcc2.c'.
463:
464: The PowerPC and POWER2 architectures are now supported, but
465: have not been extensively tested due to lack of appropriate
466: systems. Only AIX is supported on the PowerPC.
467:
468: XLC version 1.3.0.0 will miscompile `jump.c'. XLC version
469: 1.3.0.1 or later fixes this problem. We do not yet have a
470: PTF number for this fix.
471:
472: `vax-dec-ultrix'
473: Don't try compiling with Vax C (`vcc'). It produces
474: incorrect code in some cases (for example, when `alloca' is
475: used).
476:
477: Meanwhile, compiling `cp-parse.c' with pcc does not work
478: because of an internal table size limitation in that
479: compiler. To avoid this problem, compile just the GNU C
480: compiler first, and use it to recompile building all the
481: languages that you want to run.
482:
483: Here we spell out what files will be set up by `configure'.
484: Normally you need not be concerned with these files.
485:
486: * A symbolic link named `config.h' is made to the top-level
487: config file for the machine you will run the compiler on
488: (*note Config::.). This file is responsible for defining
489: information about the host machine. It includes `tm.h'.
490:
491: The top-level config file is located in the subdirectory
492: `config'. Its name is always `xm-SOMETHING.h'; usually
493: `xm-MACHINE.h', but there are some exceptions.
494:
495: If your system does not support symbolic links, you might
496: want to set up `config.h' to contain a `#include' command
497: which refers to the appropriate file.
498:
499: * A symbolic link named `tconfig.h' is made to the top-level
500: config file for your target machine. This is used for
501: compiling certain programs to run on that machine.
502:
503: * A symbolic link named `tm.h' is made to the
504: machine-description macro file for your target machine. It
505: should be in the subdirectory `config' and its name is often
506: `MACHINE.h'.
507:
508: * A symbolic link named `md' will be made to the machine
509: description pattern file. It should be in the `config'
510: subdirectory and its name should be `MACHINE.md'; but MACHINE
511: is often not the same as the name used in the `tm.h' file
512: because the `md' files are more general.
513:
514: * A symbolic link named `aux-output.c' will be made to the
515: output subroutine file for your machine. It should be in the
516: `config' subdirectory and its name should be `MACHINE.c'.
517:
518: * The command file `configure' also constructs the file
519: `Makefile' by adding some text to the template file
520: `Makefile.in'. The additional text comes from files in the
521: `config' directory, named `t-TARGET' and `x-HOST'. If these
522: files do not exist, it means nothing needs to be added for a
523: given target or host.
524:
525: 4. The standard directory for installing GNU CC is `/usr/local/lib'.
526: If you want to install its files somewhere else, specify
527: `--prefix=DIR' when you run `configure'. Here DIR is a directory
528: name to use instead of `/usr/local' for all purposes with one
529: exception: the directory `/usr/local/include' is searched for
530: header files no matter where you install the compiler.
531:
532: 5. Specify `--local-prefix=DIR' if you want the compiler to search
533: directory `DIR/include' for header files *instead* of
534: `/usr/local/include'. (This is for systems that have different
535: conventions for where to put site-specific things.)
536:
537: 6. Make sure the Bison parser generator is installed. (This is
538: unnecessary if the Bison output files `c-parse.c' and `cexp.c' are
539: more recent than `c-parse.y' and `cexp.y' and you do not plan to
540: change the `.y' files.)
541:
542: Bison versions older than Sept 8, 1988 will produce incorrect
543: output for `c-parse.c'.
544:
545: 7. Build the compiler. Just type `make LANGUAGES=c' in the compiler
546: directory.
547:
548: `LANGUAGES=c' specifies that only the C compiler should be
549: compiled. The makefile normally builds compilers for all the
550: supported languages; currently, C, C++ and Objective C. However,
551: C is the only language that is sure to work when you build with
552: other non-GNU C compilers. In addition, building anything but C
553: at this stage is a waste of time.
554:
555: In general, you can specify the languages to build by typing the
556: argument `LANGUAGES="LIST"', where LIST is one or more words from
557: the list `c', `c++', and `objective-c'.
558:
559: Ignore any warnings you may see about "statement not reached" in
560: `insn-emit.c'; they are normal. Also, warnings about "unknown
561: escape sequence" are normal in `genopinit.c' and perhaps some
562: other files. Any other compilation errors may represent bugs in
563: the port to your machine or operating system, and should be
564: investigated and reported (*note Bugs::.).
565:
566: Some commercial compilers fail to compile GNU CC because they have
567: bugs or limitations. For example, the Microsoft compiler is said
568: to run out of macro space. Some Ultrix compilers run out of
569: expression space; then you need to break up the statement where
570: the problem happens.
571:
572: If you are building with a previous GNU C compiler, do not use
573: `CC=gcc' on the make command or by editing the Makefile. Instead,
574: use a full pathname to specify the compiler, such as
575: `CC=/usr/local/bin/gcc'. This is because make might execute the
576: `gcc' in the current directory before all of the compiler
577: components have been built.
578:
579: 8. If you are building a cross-compiler, stop here. *Note
580: Cross-Compiler::.
581:
582: 9. Move the first-stage object files and executables into a
583: subdirectory with this command:
584:
585: make stage1
586:
587: The files are moved into a subdirectory named `stage1'. Once
588: installation is complete, you may wish to delete these files with
589: `rm -r stage1'.
590:
591: 10. If you have chosen a configuration for GNU CC which requires other
592: GNU tools (such as GAS or the GNU linker) instead of the standard
593: system tools, install the required tools in the `stage1'
594: subdirectory under the names `as', `ld' or whatever is
595: appropriate. This will enable the stage 1 compiler to find the
596: proper tools in the following stage.
597:
598: Alternatively, you can do subsequent compilation using a value of
599: the `PATH' environment variable such that the necessary GNU tools
600: come before the standard system tools.
601:
602: 11. Recompile the compiler with itself, with this command:
603:
604: make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O"
605:
606: This is called making the stage 2 compiler.
607:
608: The command shown above builds compilers for all the supported
609: languages. If you don't want them all, you can specify the
610: languages to build by typing the argument `LANGUAGES="LIST"'. LIST
611: should contain one or more words from the list `c', `c++',
612: `objective-c', and `proto'. Separate the words with spaces.
613: `proto' stands for the programs `protoize' and `unprotoize'; they
614: are not a separate language, but you use `LANGUAGES' to enable or
615: disable their installation.
616:
617: If you are going to build the stage 3 compiler, then you might
618: want to build only the C language in stage 2.
619:
620: Once you have built the stage 2 compiler, if you are short of disk
621: space, you can delete the subdirectory `stage1'.
622:
623: On a 68000 or 68020 system lacking floating point hardware, unless
624: you have selected a `tm.h' file that expects by default that there
625: is no such hardware, do this instead:
626:
627: make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O -msoft-float"
628:
629: 12. If you wish to test the compiler by compiling it with itself one
630: more time, install any other necessary GNU tools (such as GAS or
631: the GNU linker) in the `stage2' subdirectory as you did in the
632: `stage1' subdirectory, then do this:
633:
634: make stage2
635: make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O"
636:
637: This is called making the stage 3 compiler. Aside from the `-B'
638: option, the compiler options should be the same as when you made
639: the stage 2 compiler. But the `LANGUAGES' option need not be the
640: same. The command shown above builds compilers for all the
641: supported languages; if you don't want them all, you can specify
642: the languages to build by typing the argument `LANGUAGES="LIST"',
643: as described above.
644:
645: Then compare the latest object files with the stage 2 object
646: files--they ought to be identical, unless they contain time stamps.
647: You can compare the files, disregarding the time stamps if any,
648: like this:
649:
650: make compare
651:
652: This will mention any object files that differ between stage 2 and
653: stage 3. Any difference, no matter how innocuous, indicates that
654: the stage 2 compiler has compiled GNU CC incorrectly, and is
655: therefore a potentially serious bug which you should investigate
656: and report (*note Bugs::.).
657:
658: If your system does not put time stamps in the object files, then
659: this is a faster way to compare them (using the Bourne shell):
660:
661: for file in *.o; do
662: cmp $file stage2/$file
663: done
664:
665: If you have built the compiler with the `-mno-mips-tfile' option on
666: MIPS machines, you will not be able to compare the files.
667:
668: The Alpha stores file names in the object files and `make compare'
669: does not know how to ignore them, so normally you cannot compare
670: on the Alpha. However, if you use the `-save-temps' option when
671: compiling *both* stage 2 and stage 3, this causes the same file
672: names to be used in both stages; then you can do the comparison.
673:
674: 13. Build the Objective C library (if you have built the Objective C
675: compiler). Here is the command to do this:
676:
677: make objc-runtime CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O"
678:
679: 14. Install the compiler driver, the compiler's passes and run-time
680: support with `make install'. Use the same value for `CC',
681: `CFLAGS' and `LANGUAGES' that you used when compiling the files
682: that are being installed. One reason this is necessary is that
683: some versions of Make have bugs and recompile files gratuitously
684: when you do this step. If you use the same variable values, those
685: files will be recompiled properly.
686:
687: For example, if you have built the stage 2 compiler, you can use
688: the following command:
689:
690: make install CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" LANGUAGES="LIST"
691:
692: This copies the files `cc1', `cpp' and `libgcc.a' to files `cc1',
693: `cpp' and `libgcc.a' in the directory
694: `/usr/local/lib/gcc-lib/TARGET/VERSION', which is where the
695: compiler driver program looks for them. Here TARGET is the target
696: machine type specified when you ran `configure', and VERSION is
697: the version number of GNU CC. This naming scheme permits various
698: versions and/or cross-compilers to coexist.
699:
700: This also copies the driver program `xgcc' into
701: `/usr/local/bin/gcc', so that it appears in typical execution
702: search paths.
703:
704: On some systems, this command causes recompilation of some files.
705: This is usually due to bugs in `make'. You should either ignore
706: this problem, or use GNU Make.
707:
708: *Warning: there is a bug in `alloca' in the Sun library. To avoid
709: this bug, be sure to install the executables of GNU CC that were
710: compiled by GNU CC. (That is, the executables from stage 2 or 3,
711: not stage 1.) They use `alloca' as a built-in function and never
712: the one in the library.*
713:
714: (It is usually better to install GNU CC executables from stage 2
715: or 3, since they usually run faster than the ones compiled with
716: some other compiler.)
717:
718: 15. Install the Objective C library (if you are installing the
719: Objective C compiler). Here is the command to do this:
720:
721: make install-libobjc CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O"
722:
723: 16. If you're going to use C++, it's likely that you need to also
724: install the libg++ distribution. It should be available from the
725: same place where you got the GNU C distribution. Just as GNU C
726: does not distribute a C runtime library, it also does not include
727: a C++ run-time library. All I/O functionality, special class
728: libraries, etc., are available in the libg++ distribution.
729:
730:
731: File: gcc.info, Node: Other Dir, Next: Cross-Compiler, Up: Installation
732:
733: Compilation in a Separate Directory
734: ===================================
735:
736: If you wish to build the object files and executables in a directory
737: other than the one containing the source files, here is what you must
738: do differently:
739:
740: 1. Make sure you have a version of Make that supports the `VPATH'
741: feature. (GNU Make supports it, as do Make versions on most BSD
742: systems.)
743:
744: 2. If you have ever run `configure' in the source directory, you must
745: undo the configuration. Do this by running:
746:
747: make distclean
748:
749: 3. Go to the directory in which you want to build the compiler before
750: running `configure':
751:
752: mkdir gcc-sun3
753: cd gcc-sun3
754:
755: On systems that do not support symbolic links, this directory must
756: be on the same file system as the source code directory.
757:
758: 4. Specify where to find `configure' when you run it:
759:
760: ../gcc/configure ...
761:
762: This also tells `configure' where to find the compiler sources;
763: `configure' takes the directory from the file name that was used to
764: invoke it. But if you want to be sure, you can specify the source
765: directory with the `--srcdir' option, like this:
766:
767: ../gcc/configure --srcdir=../gcc sun3
768:
769: The directory you specify with `--srcdir' need not be the same as
770: the one that `configure' is found in.
771:
772: Now, you can run `make' in that directory. You need not repeat the
773: configuration steps shown above, when ordinary source files change. You
774: must, however, run `configure' again when the configuration files
775: change, if your system does not support symbolic links.
776:
777:
778: File: gcc.info, Node: Cross-Compiler, Next: PA Install, Prev: Other Dir, Up: Installation
779:
780: Building and Installing a Cross-Compiler
781: ========================================
782:
783: GNU CC can function as a cross-compiler for many machines, but not
784: all.
785:
786: * Cross-compilers for the Mips as target using the Mips assembler
787: currently do not work, because the auxiliary programs
788: `mips-tdump.c' and `mips-tfile.c' can't be compiled on anything
789: but a Mips. It does work to cross compile for a Mips if you use
790: the GNU assembler and linker.
791:
792: * Cross-compilers between machines with different floating point
793: formats have not all been made to work. GNU CC now has a floating
794: point emulator with which these can work, but each target machine
795: description needs to be updated to take advantage of it.
796:
797: * Cross-compilation between machines of different word sizes has not
798: really been addressed yet.
799:
800: Since GNU CC generates assembler code, you probably need a
801: cross-assembler that GNU CC can run, in order to produce object files.
802: If you want to link on other than the target machine, you need a
803: cross-linker as well. You also need header files and libraries suitable
804: for the target machine that you can install on the host machine.
805:
806: * Menu:
807:
808: * Steps of Cross:: Using a cross-compiler involves several steps
809: that may be carried out on different machines.
810: * Configure Cross:: Configuring a cross-compiler.
811: * Tools and Libraries:: Where to put the linker and assembler, and the C library.
812: * Cross Headers:: Finding and installing header files
813: for a cross-compiler.
814: * Cross Runtime:: Supplying arithmetic runtime routines (`libgcc1.a').
815: * Build Cross:: Actually compiling the cross-compiler.
816:
817:
818: File: gcc.info, Node: Steps of Cross, Next: Configure Cross, Up: Cross-Compiler
819:
820: Steps of Cross-Compilation
821: --------------------------
822:
823: To compile and run a program using a cross-compiler involves several
824: steps:
825:
826: * Run the cross-compiler on the host machine to produce assembler
827: files for the target machine. This requires header files for the
828: target machine.
829:
830: * Assemble the files produced by the cross-compiler. You can do this
831: either with an assembler on the target machine, or with a
832: cross-assembler on the host machine.
833:
834: * Link those files to make an executable. You can do this either
835: with a linker on the target machine, or with a cross-linker on the
836: host machine. Whichever machine you use, you need libraries and
837: certain startup files (typically `crt....o') for the target
838: machine.
839:
840: It is most convenient to do all of these steps on the same host
841: machine, since then you can do it all with a single invocation of GNU
842: CC. This requires a suitable cross-assembler and cross-linker. For
843: some targets, the GNU assembler and linker are available.
844:
845:
846: File: gcc.info, Node: Configure Cross, Next: Tools and Libraries, Prev: Steps of Cross, Up: Cross-Compiler
847:
848: Configuring a Cross-Compiler
849: ----------------------------
850:
851: To build GNU CC as a cross-compiler, you start out by running
852: `configure'. You must specify two different configurations, the host
853: and the target. Use the `--host=HOST' option for the host and
854: `--target=TARGET' to specify the target type. For example, here is how
855: to configure for a cross-compiler that runs on a hypothetical Intel 386
856: system and produces code for an HP 68030 system running BSD:
857:
858: configure --target=m68k-hp-bsd4.3 --host=i386-bozotheclone-bsd4.3
859:
860:
861: File: gcc.info, Node: Tools and Libraries, Next: Cross Headers, Prev: Configure Cross, Up: Cross-Compiler
862:
863: Tools and Libraries for a Cross-Compiler
864: ----------------------------------------
865:
866: If you have a cross-assembler and cross-linker available, you should
867: install them now. Put them in the directory `/usr/local/TARGET/bin'.
868: Here is a table of the tools you should put in this directory:
869:
870: `as'
871: This should be the cross-assembler.
872:
873: `ld'
874: This should be the cross-linker.
875:
876: `ar'
877: This should be the cross-archiver: a program which can manipulate
878: archive files (linker libraries) in the target machine's format.
879:
880: `ranlib'
881: This should be a program to construct a symbol table in an archive
882: file.
883:
884: The installation of GNU CC will find these programs in that
885: directory, and copy or link them to the proper place to for the
886: cross-compiler to find them when run later.
887:
888: The easiest way to provide these files is to build the Binutils
889: package and GAS. Configure them with the same `--host' and `--target'
890: options that you use for configuring GNU CC, then build and install
891: them. They install their executables automatically into the proper
892: directory. Alas, they do not support all the targets that GNU CC
893: supports.
894:
895: If you want to install libraries to use with the cross-compiler,
896: such as a standard C library, put them in the directory
897: `/usr/local/TARGET/lib'; installation of GNU CC copies all all the
898: files in that subdirectory into the proper place for GNU CC to find
899: them and link with them. Here's an example of copying some libraries
900: from a target machine:
901:
902: ftp TARGET-MACHINE
903: lcd /usr/local/TARGET/lib
904: cd /lib
905: get libc.a
906: cd /usr/lib
907: get libg.a
908: get libm.a
909: quit
910:
911: The precise set of libraries you'll need, and their locations on the
912: target machine, vary depending on its operating system.
913:
914: Many targets require "start files" such as `crt0.o' and `crtn.o'
915: which are linked into each executable; these too should be placed in
916: `/usr/local/TARGET/lib'. There may be several alternatives for
917: `crt0.o', for use with profiling or other compilation options. Check
918: your target's definition of `STARTFILE_SPEC' to find out what start
919: files it uses. Here's an example of copying these files from a target
920: machine:
921:
922: ftp TARGET-MACHINE
923: lcd /usr/local/TARGET/lib
924: prompt
925: cd /lib
926: mget *crt*.o
927: cd /usr/lib
928: mget *crt*.o
929: quit
930:
931:
932: File: gcc.info, Node: Cross Runtime, Next: Build Cross, Prev: Cross Headers, Up: Cross-Compiler
933:
934: `libgcc.a' and Cross-Compilers
935: ------------------------------
936:
937: Code compiled by GNU CC uses certain runtime support functions
938: implicitly. Some of these functions can be compiled successfully with
939: GNU CC itself, but a few cannot be. These problem functions are in the
940: source file `libgcc1.c'; the library made from them is called
941: `libgcc1.a'.
942:
943: When you build a native compiler, these functions are compiled with
944: some other compiler-the one that you use for bootstrapping GNU CC.
945: Presumably it knows how to open code these operations, or else knows how
946: to call the run-time emulation facilities that the machine comes with.
947: But this approach doesn't work for building a cross-compiler. The
948: compiler that you use for building knows about the host system, not the
949: target system.
950:
951: So, when you build a cross-compiler you have to supply a suitable
952: library `libgcc1.a' that does the job it is expected to do.
953:
954: To compile `libgcc1.c' with the cross-compiler itself does not work.
955: The functions in this file are supposed to implement arithmetic
956: operations that GNU CC does not know how to open code, for your target
957: machine. If these functions are compiled with GNU CC itself, they will
958: compile into infinite recursion.
959:
960: On any given target, most of these functions are not needed. If GNU
961: CC can open code an arithmetic operation, it will not call these
962: functions to perform the operation. It is possible that on your target
963: machine, none of these functions is needed. If so, you can supply an
964: empty library as `libgcc1.a'.
965:
966: Many targets need library support only for multiplication and
967: division. If you are linking with a library that contains functions for
968: multiplication and division, you can tell GNU CC to call them directly
969: by defining the macros `MULSI3_LIBCALL', and the like. These macros
970: need to be defined in the target description macro file. For some
971: targets, they are defined already. This may be sufficient to avoid the
972: need for libgcc1.a; if so, you can supply an empty library.
973:
974: Some targets do not have floating point instructions; they need other
975: functions in `libgcc1.a', which do floating arithmetic. Recent
976: versions of GNU CC have a file which emulates floating point. With a
977: certain amount of work, you should be able to construct a floating
978: point emulator that can be used as `libgcc1.a'. Perhaps future
979: versions will contain code to do this automatically and conveniently.
980: That depends on whether someone wants to implement it.
981:
982: If your target system has another C compiler, you can configure GNU
983: CC as a native compiler on that machine, build just `libgcc1.a' with
984: `make libgcc1.a' on that machine, and use the resulting file with the
985: cross-compiler. To do this, execute the following on the target
986: machine:
987:
988: cd TARGET-BUILD-DIR
989: configure --host=sparc --target=sun3
990: make libgcc1.a
991:
992: And then this on the host machine:
993:
994: ftp TARGET-MACHINE
995: binary
996: cd TARGET-BUILD-DIR
997: get libgcc1.a
998: quit
999:
1000: Another way to provide the functions you need in `libgcc1.a' is to
1001: define the appropriate `perform_...' macros for those functions. If
1002: these definitions do not use the C arithmetic operators that they are
1003: meant to implement, you should be able to compile them with the
1004: cross-compiler you are building. (If these definitions already exist
1005: for your target file, then you are all set.)
1006:
1007: To build `libgcc1.a' using the perform macros, use
1008: `LIBGCC1=libgcc1.a OLDCC=./xgcc' when building the compiler.
1009: Otherwise, you should place your replacement library under the name
1010: `libgcc1.a' in the directory in which you will build the
1011: cross-compiler, before you run `make'.
1012:
1013:
1014: File: gcc.info, Node: Cross Headers, Next: Cross Runtime, Prev: Tools and Libraries, Up: Cross-Compiler
1015:
1016: Cross-Compilers and Header Files
1017: --------------------------------
1018:
1019: If you are cross-compiling a standalone program or a program for an
1020: embedded system, then you may not need any header files except the few
1021: that are part of GNU CC (and those of your program). However, if you
1022: intend to link your program with a standard C library such as `libc.a',
1023: then you probably need to compile with the header files that go with
1024: the library you use.
1025:
1026: The GNU C compiler does not come with these files, because (1) they
1027: are system-specific, and (2) they belong in a C library, not in a
1028: compiler.
1029:
1030: If the GNU C library supports your target machine, then you can get
1031: the header files from there (assuming you actually use the GNU library
1032: when you link your program).
1033:
1034: If your target machine comes with a C compiler, it probably comes
1035: with suitable header files also. If you make these files accessible
1036: from the host machine, the cross-compiler can use them also.
1037:
1038: Otherwise, you're on your own in finding header files to use when
1039: cross-compiling.
1040:
1041: When you have found suitable header files, put them in
1042: `/usr/local/TARGET/include', before building the cross compiler. Then
1043: installation will run fixincludes properly and install the corrected
1044: versions of the header files where the compiler will use them.
1045:
1046: Provide the header files before you build the cross-compiler, because
1047: the build stage actually runs the cross-compiler to produce parts of
1048: `libgcc.a'. (These are the parts that *can* be compiled with GNU CC.)
1049: Some of them need suitable header files.
1050:
1051: Here's an example showing how to copy the header files from a target
1052: machine. On the target machine, do this:
1053:
1054: (cd /usr/include; tar cf - .) > tarfile
1055:
1056: Then, on the host machine, do this:
1057:
1058: ftp TARGET-MACHINE
1059: lcd /usr/local/TARGET/include
1060: get tarfile
1061: quit
1062: tar xf tarfile
1063:
1064:
1065: File: gcc.info, Node: Build Cross, Prev: Cross Runtime, Up: Cross-Compiler
1066:
1067: Actually Building the Cross-Compiler
1068: ------------------------------------
1069:
1070: Now you can proceed just as for compiling a single-machine compiler
1071: through the step of building stage 1. If you have not provided some
1072: sort of `libgcc1.a', then compilation will give up at the point where
1073: it needs that file, printing a suitable error message. If you do
1074: provide `libgcc1.a', then building the compiler will automatically
1075: compile and link a test program called `cross-test'; if you get errors
1076: in the linking, it means that not all of the necessary routines in
1077: `libgcc1.a' are available.
1078:
1079: If you are making a cross-compiler for an embedded system, and there
1080: is no `stdio.h' header for it, then the compilation of `enquire' will
1081: probably fail. The job of `enquire' is to run on the target machine
1082: and figure out by experiment the nature of its floating point
1083: representation. `enquire' records its findings in the header file
1084: `float.h'. If you can't produce this file by running `enquire' on the
1085: target machine, then you will need to come up with a suitable `float.h'
1086: in some other way (or else, avoid using it in your programs).
1087:
1088: Do not try to build stage 2 for a cross-compiler. It doesn't work to
1089: rebuild GNU CC as a cross-compiler using the cross-compiler, because
1090: that would produce a program that runs on the target machine, not on the
1091: host. For example, if you compile a 386-to-68030 cross-compiler with
1092: itself, the result will not be right either for the 386 (because it was
1093: compiled into 68030 code) or for the 68030 (because it was configured
1094: for a 386 as the host). If you want to compile GNU CC into 68030 code,
1095: whether you compile it on a 68030 or with a cross-compiler on a 386, you
1096: must specify a 68030 as the host when you configure it.
1097:
1098: To install the cross-compiler, use `make install', as usual.
1099:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.