![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to INSTALL CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to INSTALL CVS log | Up to [GCC 2.x] / gcc |
1.1.1.5 root 1: This file documents the installation of the GNU compiler. Copyright
2: (C) 1988, 1989, 1992 Free Software Foundation, Inc. You may copy,
1.1.1.3 root 3: distribute, and modify it freely as long as you preserve this copyright
4: notice and permission notice.
1.1 root 5:
6: Installing GNU CC
1.1.1.5 root 7: *****************
1.1 root 8:
9: Here is the procedure for installing GNU CC on a Unix system.
10:
1.1.1.6 ! root 11: You cannot install GNU C by itself on MSDOS; it will not compile
! 12: under any MSDOS compiler except itself. You need to get the complete
! 13: compilation package DJGPP, which includes binaries as well as sources,
! 14: and includes all the necessary compilation tools and libraries.
! 15:
1.1 root 16: 1. If you have built GNU CC previously in the same directory for a
1.1.1.2 root 17: different target machine, do `make distclean' to delete all files
1.1.1.4 root 18: that might be invalid. One of the files this deletes is
19: `Makefile'; if `make distclean' complains that `Makefile' does not
20: exist, it probably means that the directory is already suitably
21: clean.
1.1 root 22:
1.1.1.3 root 23: 2. On a System V release 4 system, make sure `/usr/bin' precedes
1.1 root 24: `/usr/ucb' in `PATH'. The `cc' command in `/usr/ucb' uses
25: libraries which have bugs.
26:
1.1.1.3 root 27: 3. Specify the host and target machine configurations. You do this by
28: running the file `configure' with appropriate arguments.
1.1 root 29:
1.1.1.3 root 30: If you are building a compiler to produce code for the machine it
1.1.1.6 ! root 31: runs on, specify just one machine type, with the `--target'
1.1.1.5 root 32: option; the host type will default to be the same as the target.
1.1.1.3 root 33: (For information on building a cross-compiler, see *Note
1.1.1.6 ! root 34: Cross-Compiler::.) Here is an example:
1.1 root 35:
1.1.1.3 root 36: configure --target=sparc-sun-sunos4.1
1.1 root 37:
1.1.1.6 ! root 38: If you run `configure' without specifying configuration arguments,
! 39: `configure' tries to guess the type of host you are on, and uses
! 40: that configuration type for both host and target. So you don't
! 41: need to specify a configuration, for building a native compiler,
! 42: unless `configure' cannot figure out what your configuration is.
! 43:
1.1.1.3 root 44: A configuration name may be canonical or it may be more or less
1.1 root 45: abbreviated.
46:
1.1.1.3 root 47: A canonical configuration name has three parts, separated by
1.1.1.5 root 48: dashes. It looks like this: `CPU-COMPANY-SYSTEM'. (The three
49: parts may themselves contain dashes; `configure' can figure out
50: which dashes serve which purpose.) For example,
51: `m68k-sun-sunos4.1' specifies a Sun 3.
1.1 root 52:
1.1.1.3 root 53: You can also replace parts of the configuration by nicknames or
1.1.1.5 root 54: aliases. For example, `sun3' stands for `m68k-sun', so
1.1 root 55: `sun3-sunos4.1' is another way to specify a Sun 3. You can also
1.1.1.2 root 56: use simply `sun3-sunos', since the version of SunOS is assumed by
1.1.1.3 root 57: default to be version 4. `sun3-bsd' also works, since `configure'
58: knows that the only BSD variant on a Sun 3 is SunOS.
59:
60: You can specify a version number after any of the system types,
61: and some of the CPU types. In most cases, the version is
62: irrelevant, and will be ignored. So you might as well specify the
63: version if you know it.
1.1 root 64:
1.1.1.3 root 65: Here are the possible CPU types:
66:
1.1.1.5 root 67: a29k, alpha, arm, cN, clipper, elxsi, h8300, hppa1.0, hppa1.1,
1.1.1.6 ! root 68: i370, i386, i486, i860, i960, m68000, m68k, m88k, mips,
! 69: ns32k, pyramid, romp, rs6000, sh, sparc, sparclite, vax,
! 70: we32k.
1.1.1.3 root 71:
72: Here are the recognized company names. As you can see, customary
73: abbreviations are used rather than the longer official names.
1.1 root 74:
1.1.1.5 root 75: alliant, altos, apollo, att, bull, cbm, convergent, convex,
76: crds, dec, dg, dolphin, elxsi, encore, harris, hitachi, hp,
77: ibm, intergraph, isi, mips, motorola, ncr, next, ns, omron,
78: plexus, sequent, sgi, sony, sun, tti, unicom.
1.1 root 79:
1.1.1.3 root 80: The company name is meaningful only to disambiguate when the rest
81: of the information supplied is insufficient. You can omit it,
82: writing just `CPU-SYSTEM', if it is not needed. For example,
1.1 root 83: `vax-ultrix4.2' is equivalent to `vax-dec-ultrix4.2'.
84:
1.1.1.3 root 85: Here is a list of system types:
1.1 root 86:
1.1.1.5 root 87: aix, acis, aos, bsd, clix, ctix, dgux, dynix, genix, hpux,
1.1.1.6 ! root 88: isc, linux, luna, lynxos, mach, minix, newsos, osf, osfrose,
! 89: riscos, sco, solaris, sunos, sysv, ultrix, unos, vms.
1.1 root 90:
91: You can omit the system type; then `configure' guesses the
92: operating system from the CPU and company.
93:
1.1.1.3 root 94: You can add a version number to the system type; this may or may
95: not make a difference. For example, you can write `bsd4.3' or
1.1.1.2 root 96: `bsd4.4' to distinguish versions of BSD. In practice, the version
97: number is most needed for `sysv3' and `sysv4', which are often
98: treated differently.
99:
1.1.1.3 root 100: If you specify an impossible combination such as `i860-dg-vms',
1.1.1.2 root 101: then you may get an error message from `configure', or it may
102: ignore part of the information and do the best it can with the
1.1.1.5 root 103: rest. `configure' always prints the canonical name for the
1.1.1.2 root 104: alternative that it used.
105:
1.1.1.3 root 106: Often a particular model of machine has a name. Many machine
1.1.1.5 root 107: names are recognized as aliases for CPU/company combinations.
1.1.1.2 root 108: Thus, the machine name `sun3', mentioned above, is an alias for
1.1.1.5 root 109: `m68k-sun'. Sometimes we accept a company name as a machine name,
1.1.1.3 root 110: when the name is popularly used for a particular machine. Here is
111: a table of the known machine names:
112:
113: 3300, 3b1, 3bN, 7300, altos3068, altos, apollo68, att-7300,
114: balance, convex-cN, crds, decstation-3100, decstation, delta,
115: encore, fx2800, gmicro, hp7NN, hp8NN, hp9k2NN, hp9k3NN,
116: hp9k7NN, hp9k8NN, iris4d, iris, isi68, m3230, magnum, merlin,
117: miniframe, mmax, news-3600, news800, news, next, pbd, pc532,
118: pmax, ps2, risc-news, rtpc, sun2, sun386i, sun386, sun3,
119: sun4, symmetry, tower-32, tower.
1.1 root 120:
1.1.1.2 root 121: Remember that a machine name specifies both the cpu type and the
122: company name.
1.1 root 123:
1.1.1.4 root 124: There are four additional options you can specify independently to
1.1.1.3 root 125: describe variant hardware and software configurations. These are
1.1.1.4 root 126: `--with-gnu-as', `--with-gnu-ld', `--with-stabs' and `--nfp'.
1.1.1.3 root 127:
128: `--with-gnu-as'
1.1.1.5 root 129: If you will use GNU CC with the GNU assembler (GAS), you
130: should declare this by using the `--with-gnu-as' option when
131: you run `configure'.
132:
133: Using this option does not install GAS. It only modifies the
134: output of GNU CC to work with GAS. Building and installing
135: GAS is up to you.
136:
1.1.1.6 ! root 137: Conversely, if you *do not* wish to use GAS and do not specify
! 138: `--with-gnu-as' when building GNU CC, it is up to you to make
! 139: sure that GAS is not installed. GNU CC searches for a
! 140: program named `as' in various directories; if the program it
! 141: finds is GAS, then it runs GAS. If you are not sure where
! 142: GNU CC finds the assembler it is using, try specifying `-v'
! 143: when you run it.
1.1.1.5 root 144:
1.1.1.6 ! root 145: The systems where it makes a difference whether you use GAS
! 146: are
! 147: `hppa1.0-ANY-ANY', `hppa1.1-ANY-ANY', `i386-ANY-sysv',
! 148: `i386-ANY-isc',
! 149: `i860-ANY-bsd', `m68k-bull-sysv', `m68k-hp-hpux',
! 150: `m68k-sony-bsd',
! 151: `m68k-altos-sysv', `m68000-hp-hpux', `m68000-att-sysv', and
! 152: `mips-ANY'). On any other system, `--with-gnu-as' has no
! 153: effect.
! 154:
! 155: On the systems listed above (except for the HP-PA and for ISC
! 156: on the 386), if you use GAS, you should also use the GNU
! 157: linker (and specify `--with-gnu-ld').
1.1.1.3 root 158:
159: `--with-gnu-ld'
160: Specify the option `--with-gnu-ld' if you plan to use the GNU
1.1.1.5 root 161: linker with GNU CC.
162:
163: This option does not cause the GNU linker to be installed; it
164: just modifies the behavior of GNU CC to work with the GNU
165: linker. Specifically, it inhibits the installation of
166: `collect2', a program which otherwise serves as a front-end
167: for the system's linker on most configurations.
1.1.1.3 root 168:
1.1.1.4 root 169: `--with-stabs'
1.1.1.6 ! root 170: On MIPS based systems and on Alphas, you must specify whether
! 171: you want GNU CC to create the normal ECOFF debugging format,
! 172: or to use BSD-style stabs passed through the ECOFF symbol
! 173: table. The normal ECOFF debug format cannot fully handle
! 174: languages other than C. BSD stabs format can handle other
! 175: languages, but it only works with the GNU debugger GDB.
1.1.1.4 root 176:
177: Normally, GNU CC uses the ECOFF debugging format by default;
178: if you prefer BSD stabs, specify `--with-stabs' when you
179: configure GNU CC.
180:
181: No matter which default you choose when you configure GNU CC,
182: the user can use the `-gcoff' and `-gstabs+' options to
183: specify explicitly the debug format for a particular
184: compilation.
185:
1.1.1.6 ! root 186: `--with-stabs' is meaningful on the ISC system on the 386,
! 187: also, if `--with-gas' is used. It selects use of stabs
! 188: debugging information embedded in COFF output. This kind of
! 189: debugging information supports C++ well; ordinary COFF
! 190: debugging information does not.
! 191:
1.1.1.3 root 192: `--nfp'
193: On certain systems, you must specify whether the machine has
1.1.1.5 root 194: a floating point unit. These systems include
195: `m68k-sun-sunosN' and `m68k-isi-bsd'. On any other system,
196: `--nfp' currently has no effect, though perhaps there are
197: other systems where it could usefully make a difference.
1.1.1.3 root 198:
199: If you want to install your own homemade configuration files, you
200: can use `local' as the company name to access them. If you use
1.1.1.5 root 201: configuration `CPU-local', the configuration name without the cpu
202: prefix is used to form the configuration file names.
1.1 root 203:
1.1.1.5 root 204: Thus, if you specify `m68k-local', configuration uses files
205: `local.md', `local.h', `local.c', `xm-local.h', `t-local', and
206: `x-local', all in the directory `config/m68k'.
1.1 root 207:
1.1.1.3 root 208: Here is a list of configurations that have special treatment or
209: special things you must know:
1.1.1.2 root 210:
1.1.1.4 root 211: `alpha-*-osf1'
212: Systems using processors that implement the DEC Alpha
1.1.1.5 root 213: architecture and are running the OSF/1 operating system, for
214: example the DEC Alpha AXP systems. (VMS on the Alpha is not
215: currently supported by GNU CC.)
216:
1.1.1.6 ! root 217: Objective C and C++ do not yet work on the Alpha. We hope to
! 218: support C++ in version 2.6.
! 219:
1.1.1.5 root 220: GNU CC writes a `.verstamp' directive to the assembler output
221: file unless it is built as a cross-compiler. It gets the
222: version to use from the system header file
223: `/usr/include/stamp.h'. If you install a new version of
224: OSF/1, you should rebuild GCC to pick up the new version
225: stamp.
1.1.1.4 root 226:
227: Note that since the Alpha is a 64-bit architecture,
228: cross-compilers from 32-bit machines will not generate as
229: efficient code as that generated when the compiler is running
230: on a 64-bit machine because many optimizations that depend on
231: being able to represent a word on the target in an integral
1.1.1.5 root 232: value on the host cannot be performed. Building
1.1.1.6 ! root 233: cross-compilers on the Alpha for 32-bit machines has only
! 234: been tested in a few cases and may not work properly.
! 235:
! 236: `make compare' may fail on some versions of OSF/1 unless you
! 237: add `-save-temps' to `CFLAGS'. The same problem occurs on
! 238: Irix version 5.1.1. On these systems, the name of the
! 239: assembler input file is stored in the object file, and that
! 240: makes comparison fail if it differs between the `stage1' and
! 241: `stage2' compilations. The option `-save-temps' forces a
! 242: fixed name to be used for the assembler input file, instead
! 243: of a randomly chosen name in `/tmp'.
! 244:
! 245: GNU CC now supports both the native (ECOFF) debugging format
! 246: used by DBX and GDB and an encapsulated STABS format for use
! 247: only with GDB. See the discussion of the `--with-stabs'
! 248: option of `configure' above for more information on these
! 249: formats and how to select them.
! 250:
! 251: There is a bug in DEC's assembler that produces incorrect
! 252: line numbers for ECOFF format when the `.align' directive is
! 253: used. To work around this problem, GNU CC will not emit such
! 254: alignment directives even if optimization is being performed
! 255: if it is writing ECOFF format debugging information.
! 256: Unfortunately, this has the very undesirable side-effect that
! 257: code addresses when `-O' is specified are different depending
! 258: on whether or not `-g' is also specified.
! 259:
! 260: To avoid this behavior, specify `-gstabs+' and use GDB
! 261: instead of DBX. DEC is now aware of this problem with the
! 262: assembler and hopes to provide a fix shortly.
1.1.1.4 root 263:
264: `a29k'
1.1.1.5 root 265: AMD Am29k-family processors. These are normally used in
1.1.1.4 root 266: embedded applications. There are no standard Unix
1.1.1.5 root 267: configurations. This configuration corresponds to AMD's
1.1.1.4 root 268: standard calling sequence and binary interface and is
1.1.1.5 root 269: compatible with other 29k tools.
1.1.1.4 root 270:
271: You may need to make a variant of the file `a29k.h' for your
272: particular configuration.
273:
274: `a29k-*-bsd'
275: AMD Am29050 used in a system running a variant of BSD Unix.
276:
277: `elxsi-elxsi-bsd'
278: The Elxsi's C compiler has known limitations that prevent it
279: from compiling GNU C. Please contact `[email protected]' for
280: more details.
281:
1.1.1.6 ! root 282: `hppa*-*-*'
! 283: Using GAS is highly recommended for all HP-PA configurations.
! 284: See *Note PA Install:: for the special procedures needed to
! 285: compile GNU CC for the HP-PA.
! 286:
1.1.1.2 root 287: `i386-*-sco'
1.1.1.5 root 288: Compilation with RCC is recommended. Also, it may be a good
289: idea to link with GNU malloc instead of the malloc that comes
290: with the system.
291:
1.1.1.6 ! root 292: `i386-*-sco3.2.4'
! 293: Use this configuration for SCO release 3.2 version 4.
! 294:
1.1.1.5 root 295: `i386-*-isc'
296: It may be good idea to link with GNU malloc instead of the
297: malloc that comes with the system.
298:
299: `i386-*-esix'
300: It may be good idea to link with GNU malloc instead of the
301: malloc that comes with the system.
1.1.1.4 root 302:
303: `i386-ibm-aix'
1.1.1.5 root 304: You need to use GAS version 2.1 or later, and and LD from GNU
305: binutils version 2.2 or later.
1.1 root 306:
1.1.1.3 root 307: `i386-sequent'
308: Go to the Berkeley universe before compiling. In addition,
309: you probably need to create a file named `string.h'
310: containing just one line: `#include <strings.h>'.
311:
1.1.1.4 root 312: `i386-sun-sunos4'
313: You may find that you need another version of GNU CC to begin
314: bootstrapping with, since the current version when built with
315: the system's own compiler seems to get an infinite loop
316: compiling part of `libgcc2.c'. GNU CC version 2 compiled
317: with GNU CC (any version) seems not to have this problem.
318:
1.1.1.6 ! root 319: `i860-intel-osf1'
! 320: This is the Paragon. If you have version 1.0 of the
! 321: operating system, you need to take special steps to build GNU
! 322: CC due to peculiarities of the system. Newer system versions
! 323: have no problem. See the section `Installation Problems' in
! 324: the GNU CC Manual.
! 325:
1.1 root 326: `m68000-att'
327: AT&T 3b1, a.k.a. 7300 PC. Special procedures are needed to
328: compile GNU CC with this machine's standard C compiler, due
329: to bugs in that compiler. *Note 3b1 Install::. You can
330: bootstrap it more easily with previous versions of GNU CC if
331: you have them.
332:
333: `m68000-hp-bsd'
334: HP 9000 series 200 running BSD. Note that the C compiler
335: that comes with this system cannot compile GNU CC; contact
1.1.1.3 root 336: `[email protected]' to get binaries of GNU CC for bootstrapping.
1.1 root 337:
338: `m68k-altos'
339: Altos 3068. You must use the GNU assembler, linker and
1.1.1.5 root 340: debugger. Also, you must fix a kernel bug. Details in the
341: file `README.ALTOS'.
1.1 root 342:
1.1.1.6 ! root 343: `m68k-bull-sysv'
! 344: Bull DPX/2 series 200 and 300 with BOS-2.00.45 up to
! 345: BOS-2.01. GNU CC works either with native assembler or GNU
! 346: assembler. You can use GNU assembler with native coff
! 347: generation by providing `--gas' to the configure script or
! 348: use GNU assembler with dbx-in-coff encapsulation by providing
! 349: `--gas --stabs'. For any problem with native assembler or for
! 350: availability of the DPX/2 port of GAS, contact
! 351: `[email protected]'.
! 352:
1.1 root 353: `m68k-hp-hpux'
1.1.1.2 root 354: HP 9000 series 300 or 400 running HP-UX. HP-UX version 8.0
355: has a bug in the assembler that prevents compilation of GNU
356: CC. To fix it, get patch PHCO_0800 from HP.
357:
358: In addition, `--gas' does not currently work with this
359: configuration. Changes in HP-UX have broken the library
360: conversion tool and the linker.
1.1 root 361:
362: `m68k-sun'
1.1.1.3 root 363: Sun 3. We do not provide a configuration file to use the Sun
364: FPA by default, because programs that establish signal
365: handlers for floating point traps inherently cannot work with
366: the FPA.
367:
1.1.1.5 root 368: `m88k-*-svr3'
1.1.1.4 root 369: Motorola m88k running the AT&T/Unisoft/Motorola V.3 reference
1.1.1.5 root 370: port. These systems tend to use the Green Hills C, revision
1.1.1.3 root 371: 1.8.5, as the standard C compiler. There are apparently bugs
372: in this compiler that result in object files differences
373: between stage 2 and stage 3. If this happens, make the stage
374: 4 compiler and compare it to the stage 3 compiler. If the
375: stage 3 and stage 4 object files are identical, this suggests
1.1.1.5 root 376: you encountered a problem with the standard C compiler; the
377: stage 3 and 4 compilers may be usable.
378:
379: It is best, however, to use an older version of GNU CC for
380: bootstrapping if you have one.
1.1 root 381:
1.1.1.5 root 382: `m88k-*-dgux'
1.1 root 383: Motorola m88k running DG/UX. To build native or cross
384: compilers on DG/UX, you must first change to the 88open BCS
385: software development environment. This is done by issuing
386: this command:
387:
388: eval `sde-target m88kbcs`
389:
1.1.1.5 root 390: `m88k-tektronix-sysv3'
391: Tektronix XD88 running UTekV 3.2e. Do not turn on
392: optimization while building stage1 if you bootstrap with the
393: buggy Green Hills compiler. Also, The bundled LAI System V
394: NFS is buggy so if you build in an NFS mounted directory,
395: start from a fresh reboot, or avoid NFS all together.
396: Otherwise you may have trouble getting clean comparisons
397: between stages.
398:
1.1.1.2 root 399: `mips-mips-bsd'
1.1.1.5 root 400: MIPS machines running the MIPS operating system in BSD mode.
1.1.1.3 root 401: It's possible that some old versions of the system lack the
1.1.1.2 root 402: functions `memcpy', `memcmp', and `memset'. If your system
403: lacks these, you must remove or undo the definition of
404: `TARGET_MEM_FUNCTIONS' in `mips-bsd.h'.
405:
1.1.1.5 root 406: `mips-sgi-*'
407: Silicon Graphics MIPS machines running IRIX. In order to
408: compile GCC on an SGI the "c.hdr.lib" option must be
409: installed from the CD-ROM supplied from Silicon Graphics.
410: This is found on the 2nd CD in release 4.0.1.
411:
1.1.1.3 root 412: `mips-sony-sysv'
413: Sony MIPS NEWS. This works in NEWSOS 5.0.1, but not in 5.0.2
414: (which uses ELF instead of COFF). Support for 5.0.2 will
1.1.1.5 root 415: probably be provided soon by volunteers. In particular, the
416: linker does not like the code generated by GCC when shared
417: libraries are linked in.
1.1.1.3 root 418:
1.1 root 419: `ns32k-encore'
420: Encore ns32000 system. Encore systems are supported only
421: under BSD.
422:
423: `ns32k-*-genix'
424: National Semiconductor ns32000 system. Genix has bugs in
425: `alloca' and `malloc'; you must get the compiled versions of
426: these from GNU Emacs.
427:
1.1.1.3 root 428: `ns32k-sequent'
429: Go to the Berkeley universe before compiling. In addition,
430: you probably need to create a file named `string.h'
431: containing just one line: `#include <strings.h>'.
432:
1.1 root 433: `ns32k-utek'
434: UTEK ns32000 system ("merlin"). The C compiler that comes
435: with this system cannot compile GNU CC; contact
436: `tektronix!reed!mason' to get binaries of GNU CC for
437: bootstrapping.
438:
1.1.1.3 root 439: `romp-*-aos'
440: `romp-*-mach'
441: The only operating systems supported for the IBM RT PC are
442: AOS and MACH. GNU CC does not support AIX running on the RT.
1.1.1.5 root 443: We recommend you compile GNU CC with an earlier version of
1.1.1.4 root 444: itself; if you compile GNU CC with `hc', the Metaware
445: compiler, it will work, but you will get mismatches between
1.1.1.5 root 446: the stage 2 and stage 3 compilers in various files. These
1.1.1.4 root 447: errors are minor differences in some floating-point constants
448: and can be safely ignored; the stage 3 compiler is correct.
1.1.1.3 root 449:
450: `rs6000-*-aix'
1.1.1.4 root 451: *Read the file `README.RS6000' for information on how to get
1.1.1.5 root 452: a fix for problems in the IBM assembler that interfere with
1.1.1.4 root 453: GNU CC.* You must either obtain the new assembler or avoid
454: using the `-g' switch. Note that `Makefile.in' uses `-g' by
455: default when compiling `libgcc2.c'.
1.1 root 456:
1.1.1.6 ! root 457: The PowerPC and POWER2 architectures are now supported, but
! 458: have not been extensively tested due to lack of appropriate
! 459: systems. Only AIX is supported on the PowerPC.
! 460:
! 461: Objective C does not work on this architecture.
! 462:
! 463: XLC version 1.3.0.0 will miscompile `jump.c'. XLC version
! 464: 1.3.0.1 or later fixes this problem. We do not yet have a
! 465: PTF number for this fix.
! 466:
1.1 root 467: `vax-dec-ultrix'
468: Don't try compiling with Vax C (`vcc'). It produces
469: incorrect code in some cases (for example, when `alloca' is
470: used).
471:
472: Meanwhile, compiling `cp-parse.c' with pcc does not work
473: because of an internal table size limitation in that
474: compiler. To avoid this problem, compile just the GNU C
475: compiler first, and use it to recompile building all the
476: languages that you want to run.
477:
1.1.1.5 root 478: Here we spell out what files will be set up by `configure'.
1.1 root 479: Normally you need not be concerned with these files.
480:
481: * A symbolic link named `config.h' is made to the top-level
1.1.1.3 root 482: config file for the machine you plan to run the compiler on
483: (*note The Configuration File: (gcc.info)Config.). This file
484: is responsible for defining information about the host
485: machine. It includes `tm.h'.
1.1 root 486:
487: The top-level config file is located in the subdirectory
1.1.1.5 root 488: `config'. Its name is always `xm-SOMETHING.h'; usually
1.1 root 489: `xm-MACHINE.h', but there are some exceptions.
490:
491: If your system does not support symbolic links, you might
492: want to set up `config.h' to contain a `#include' command
493: which refers to the appropriate file.
494:
495: * A symbolic link named `tconfig.h' is made to the top-level
496: config file for your target machine. This is used for
497: compiling certain programs to run on that machine.
498:
499: * A symbolic link named `tm.h' is made to the
500: machine-description macro file for your target machine. It
501: should be in the subdirectory `config' and its name is often
502: `MACHINE.h'.
503:
504: * A symbolic link named `md' will be made to the machine
505: description pattern file. It should be in the `config'
1.1.1.3 root 506: subdirectory and its name should be `MACHINE.md'; but MACHINE
507: is often not the same as the name used in the `tm.h' file
508: because the `md' files are more general.
1.1 root 509:
510: * A symbolic link named `aux-output.c' will be made to the
1.1.1.3 root 511: output subroutine file for your machine. It should be in the
512: `config' subdirectory and its name should be `MACHINE.c'.
1.1 root 513:
1.1.1.5 root 514: * The command file `configure' also constructs the file
515: `Makefile' by adding some text to the template file
516: `Makefile.in'. The additional text comes from files in the
517: `config' directory, named `t-TARGET' and `x-HOST'. If these
518: files do not exist, it means nothing needs to be added for a
519: given target or host.
520:
521: 4. The standard directory for installing GNU CC is `/usr/local/lib'.
522: If you want to install its files somewhere else, specify
523: `--prefix=DIR' when you run `configure'. Here DIR is a directory
524: name to use instead of `/usr/local' for all purposes with one
525: exception: the directory `/usr/local/include' is searched for
526: header files no matter where you install the compiler.
527:
528: 5. Specify `--local-prefix=DIR' if you want the compiler to search
529: directory `DIR/include' for header files *instead* of
530: `/usr/local/include'. (This is for systems that have different
531: conventions for where to put site-specific things.)
1.1 root 532:
1.1.1.6 ! root 533: Unless you have a convention other than `/usr/local' for
! 534: site-specific files, it is a bad idea to specify `--local-prefix'.
! 535:
1.1.1.5 root 536: 6. Make sure the Bison parser generator is installed. (This is
1.1.1.3 root 537: unnecessary if the Bison output files `c-parse.c' and `cexp.c' are
538: more recent than `c-parse.y' and `cexp.y' and you do not plan to
539: change the `.y' files.)
1.1 root 540:
1.1.1.3 root 541: Bison versions older than Sept 8, 1988 will produce incorrect
1.1 root 542: output for `c-parse.c'.
543:
1.1.1.6 ! root 544: 7. If you have chosen a configuration for GNU CC which requires other
! 545: GNU tools (such as GAS or the GNU linker) instead of the standard
! 546: system tools, install the required tools in the build directory
! 547: under the names `as', `ld' or whatever is appropriate. This will
! 548: enable the compiler to find the proper tools for compilation of
! 549: the program `enquire'.
! 550:
! 551: Alternatively, you can do subsequent compilation using a value of
! 552: the `PATH' environment variable such that the necessary GNU tools
! 553: come before the standard system tools.
! 554:
! 555: 8. Build the compiler. Just type `make LANGUAGES=c' in the compiler
1.1 root 556: directory.
557:
1.1.1.3 root 558: `LANGUAGES=c' specifies that only the C compiler should be
1.1 root 559: compiled. The makefile normally builds compilers for all the
560: supported languages; currently, C, C++ and Objective C. However,
561: C is the only language that is sure to work when you build with
562: other non-GNU C compilers. In addition, building anything but C
563: at this stage is a waste of time.
564:
1.1.1.3 root 565: In general, you can specify the languages to build by typing the
566: argument `LANGUAGES="LIST"', where LIST is one or more words from
567: the list `c', `c++', and `objective-c'.
568:
569: Ignore any warnings you may see about "statement not reached" in
1.1.1.5 root 570: `insn-emit.c'; they are normal. Also, warnings about "unknown
571: escape sequence" are normal in `genopinit.c' and perhaps some
572: other files. Any other compilation errors may represent bugs in
573: the port to your machine or operating system, and should be
574: investigated and reported.
1.1.1.3 root 575:
576: Some commercial compilers fail to compile GNU CC because they have
577: bugs or limitations. For example, the Microsoft compiler is said
578: to run out of macro space. Some Ultrix compilers run out of
1.1 root 579: expression space; then you need to break up the statement where
580: the problem happens.
581:
1.1.1.3 root 582: If you are building with a previous GNU C compiler, do not use
1.1.1.5 root 583: `CC=gcc' on the make command or by editing the Makefile. Instead,
1.1.1.3 root 584: use a full pathname to specify the compiler, such as
585: `CC=/usr/local/bin/gcc'. This is because make might execute the
586: `gcc' in the current directory before all of the compiler
587: components have been built.
588:
1.1.1.6 ! root 589: 9. If you are building a cross-compiler, stop here. *Note
1.1.1.3 root 590: Cross-Compiler::.
1.1 root 591:
1.1.1.6 ! root 592: 10. Move the first-stage object files and executables into a
1.1 root 593: subdirectory with this command:
594:
595: make stage1
596:
1.1.1.5 root 597: The files are moved into a subdirectory named `stage1'. Once
1.1 root 598: installation is complete, you may wish to delete these files with
599: `rm -r stage1'.
600:
1.1.1.6 ! root 601: 11. If you have chosen a configuration for GNU CC which requires other
1.1.1.5 root 602: GNU tools (such as GAS or the GNU linker) instead of the standard
603: system tools, install the required tools in the `stage1'
604: subdirectory under the names `as', `ld' or whatever is
605: appropriate. This will enable the stage 1 compiler to find the
606: proper tools in the following stage.
607:
608: Alternatively, you can do subsequent compilation using a value of
609: the `PATH' environment variable such that the necessary GNU tools
610: come before the standard system tools.
611:
1.1.1.6 ! root 612: 12. Recompile the compiler with itself, with this command:
1.1 root 613:
1.1.1.4 root 614: make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O"
1.1 root 615:
1.1.1.3 root 616: This is called making the stage 2 compiler.
1.1 root 617:
1.1.1.3 root 618: The command shown above builds compilers for all the supported
1.1 root 619: languages. If you don't want them all, you can specify the
1.1.1.3 root 620: languages to build by typing the argument `LANGUAGES="LIST"'. LIST
621: should contain one or more words from the list `c', `c++',
622: `objective-c', and `proto'. Separate the words with spaces.
623: `proto' stands for the programs `protoize' and `unprotoize'; they
624: are not a separate language, but you use `LANGUAGES' to enable or
625: disable their installation.
626:
627: If you are going to build the stage 3 compiler, then you might
628: want to build only the C language in stage 2.
629:
630: Once you have built the stage 2 compiler, if you are short of disk
631: space, you can delete the subdirectory `stage1'.
632:
633: On a 68000 or 68020 system lacking floating point hardware, unless
634: you have selected a `tm.h' file that expects by default that there
635: is no such hardware, do this instead:
1.1 root 636:
1.1.1.4 root 637: make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O -msoft-float"
1.1 root 638:
1.1.1.6 ! root 639: 13. If you wish to test the compiler by compiling it with itself one
1.1.1.5 root 640: more time, install any other necessary GNU tools (such as GAS or
641: the GNU linker) in the `stage2' subdirectory as you did in the
642: `stage1' subdirectory, then do this:
1.1 root 643:
644: make stage2
1.1.1.4 root 645: make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O"
1.1 root 646:
647: This is called making the stage 3 compiler. Aside from the `-B'
1.1.1.4 root 648: option, the compiler options should be the same as when you made
649: the stage 2 compiler. But the `LANGUAGES' option need not be the
650: same. The command shown above builds compilers for all the
651: supported languages; if you don't want them all, you can specify
652: the languages to build by typing the argument `LANGUAGES="LIST"',
653: as described above.
1.1 root 654:
1.1.1.3 root 655: Then compare the latest object files with the stage 2 object
1.1.1.6 ! root 656: files--they ought to be identical, aside from time stamps (if any).
! 657:
! 658: On some systems, meaningful comparison of object files is
! 659: impossible; they always appear "different." This is currently
! 660: true on Solaris and probably on all systems that use ELF object
! 661: file format. Some other systems where this is so are listed below.
! 662:
! 663: Use this command to compare the files:
1.1.1.3 root 664:
665: make compare
666:
667: This will mention any object files that differ between stage 2 and
668: stage 3. Any difference, no matter how innocuous, indicates that
669: the stage 2 compiler has compiled GNU CC incorrectly, and is
1.1 root 670: therefore a potentially serious bug which you should investigate
1.1.1.3 root 671: and report.
1.1 root 672:
1.1.1.3 root 673: If your system does not put time stamps in the object files, then
674: this is a faster way to compare them (using the Bourne shell):
1.1 root 675:
676: for file in *.o; do
1.1.1.3 root 677: cmp $file stage2/$file
1.1 root 678: done
679:
1.1.1.3 root 680: If you have built the compiler with the `-mno-mips-tfile' option on
681: MIPS machines, you will not be able to compare the files.
1.1 root 682:
1.1.1.6 ! root 683: The Alpha stores file names of internal temporary files in the
! 684: object files and `make compare' does not know how to ignore them,
! 685: so normally you cannot compare on the Alpha. However, if you use
! 686: the `-save-temps' option when compiling *both* stage 2 and stage
! 687: 3, this causes the same file names to be used in both stages; then
! 688: you can do the comparison.
! 689:
! 690: 14. Build the Objective C library (if you have built the Objective C
! 691: compiler). Here is the command to do this:
! 692:
! 693: make objc-runtime CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O"
1.1.1.5 root 694:
1.1.1.6 ! root 695: 15. Install the compiler driver, the compiler's passes and run-time
1.1.1.5 root 696: support with `make install'. Use the same value for `CC',
697: `CFLAGS' and `LANGUAGES' that you used when compiling the files
698: that are being installed. One reason this is necessary is that
699: some versions of Make have bugs and recompile files gratuitously
700: when you do this step. If you use the same variable values, those
701: files will be recompiled properly.
1.1 root 702:
1.1.1.5 root 703: For example, if you have built the stage 2 compiler, you can use
704: the following command:
1.1 root 705:
1.1.1.5 root 706: make install CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" LANGUAGES="LIST"
1.1 root 707:
1.1.1.3 root 708: This copies the files `cc1', `cpp' and `libgcc.a' to files `cc1',
1.1.1.5 root 709: `cpp' and `libgcc.a' in the directory
1.1.1.2 root 710: `/usr/local/lib/gcc-lib/TARGET/VERSION', which is where the
711: compiler driver program looks for them. Here TARGET is the target
712: machine type specified when you ran `configure', and VERSION is
713: the version number of GNU CC. This naming scheme permits various
1.1 root 714: versions and/or cross-compilers to coexist.
715:
1.1.1.5 root 716: This also copies the driver program `xgcc' into
717: `/usr/local/bin/gcc', so that it appears in typical execution
718: search paths.
719:
720: On some systems, this command causes recompilation of some files.
721: This is usually due to bugs in `make'. You should either ignore
722: this problem, or use GNU Make.
1.1.1.3 root 723:
724: *Warning: there is a bug in `alloca' in the Sun library. To avoid
725: this bug, be sure to install the executables of GNU CC that were
726: compiled by GNU CC. (That is, the executables from stage 2 or 3,
727: not stage 1.) They use `alloca' as a built-in function and never
728: the one in the library.*
1.1.1.2 root 729:
1.1.1.3 root 730: (It is usually better to install GNU CC executables from stage 2
731: or 3, since they usually run faster than the ones compiled with
1.1.1.2 root 732: some other compiler.)
1.1 root 733:
1.1.1.6 ! root 734: 16. Install the Objective C library (if you are installing the
! 735: Objective C compiler). Here is the command to do this:
1.1.1.4 root 736:
737: make install-libobjc CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O"
738:
1.1.1.6 ! root 739: 17. If you're going to use C++, it's likely that you need to also
1.1.1.5 root 740: install the libg++ distribution. It should be available from the
741: same place where you got the GNU C distribution. Just as GNU C
1.1.1.4 root 742: does not distribute a C runtime library, it also does not include
743: a C++ run-time library. All I/O functionality, special class
1.1.1.5 root 744: libraries, etc., are available in the libg++ distribution.
1.1 root 745:
746: Compilation in a Separate Directory
1.1.1.5 root 747: ===================================
1.1 root 748:
749: If you wish to build the object files and executables in a directory
750: other than the one containing the source files, here is what you must
751: do differently:
752:
753: 1. Make sure you have a version of Make that supports the `VPATH'
754: feature. (GNU Make supports it, as do Make versions on most BSD
755: systems.)
756:
1.1.1.3 root 757: 2. If you have ever run `configure' in the source directory, you must
758: undo the configuration. Do this by running:
1.1.1.2 root 759:
1.1.1.3 root 760: make distclean
1.1.1.2 root 761:
762: 3. Go to the directory in which you want to build the compiler before
763: running `configure':
1.1 root 764:
765: mkdir gcc-sun3
766: cd gcc-sun3
767:
1.1.1.3 root 768: On systems that do not support symbolic links, this directory must
769: be on the same file system as the source code directory.
1.1 root 770:
1.1.1.2 root 771: 4. Specify where to find `configure' when you run it:
1.1 root 772:
1.1.1.3 root 773: ../gcc/configure ...
1.1 root 774:
1.1.1.3 root 775: This also tells `configure' where to find the compiler sources;
776: `configure' takes the directory from the file name that was used to
777: invoke it. But if you want to be sure, you can specify the source
778: directory with the `--srcdir' option, like this:
1.1 root 779:
1.1.1.3 root 780: ../gcc/configure --srcdir=../gcc sun3
1.1 root 781:
1.1.1.3 root 782: The directory you specify with `--srcdir' need not be the same as
783: the one that `configure' is found in.
1.1 root 784:
785: Now, you can run `make' in that directory. You need not repeat the
1.1.1.3 root 786: configuration steps shown above, when ordinary source files change. You
787: must, however, run `configure' again when the configuration files
1.1 root 788: change, if your system does not support symbolic links.
789:
1.1.1.3 root 790: Building and Installing a Cross-Compiler
1.1.1.5 root 791: ========================================
1.1.1.3 root 792:
793: GNU CC can function as a cross-compiler for many machines, but not
794: all.
795:
1.1.1.6 ! root 796: * Cross-compilers for the Mips as target using the Mips assembler
! 797: currently do not work, because the auxiliary programs
! 798: `mips-tdump.c' and `mips-tfile.c' can't be compiled on anything
! 799: but a Mips. It does work to cross compile for a Mips if you use
! 800: the GNU assembler and linker.
! 801:
! 802: * Cross-compilers between machines with different floating point
! 803: formats have not all been made to work. GNU CC now has a floating
! 804: point emulator with which these can work, but each target machine
! 805: description needs to be updated to take advantage of it.
! 806:
! 807: * Cross-compilation between machines of different word sizes has not
! 808: really been addressed yet.
1.1.1.3 root 809:
810: Since GNU CC generates assembler code, you probably need a
811: cross-assembler that GNU CC can run, in order to produce object files.
812: If you want to link on other than the target machine, you need a
813: cross-linker as well. You also need header files and libraries suitable
814: for the target machine that you can install on the host machine.
815:
1.1.1.6 ! root 816: Steps of Cross-Compilation
! 817: --------------------------
! 818:
! 819: To compile and run a program using a cross-compiler involves several
! 820: steps:
! 821:
! 822: * Run the cross-compiler on the host machine to produce assembler
! 823: files for the target machine. This requires header files for the
! 824: target machine.
! 825:
! 826: * Assemble the files produced by the cross-compiler. You can do this
! 827: either with an assembler on the target machine, or with a
! 828: cross-assembler on the host machine.
! 829:
! 830: * Link those files to make an executable. You can do this either
! 831: with a linker on the target machine, or with a cross-linker on the
! 832: host machine. Whichever machine you use, you need libraries and
! 833: certain startup files (typically `crt....o') for the target
! 834: machine.
! 835:
! 836: It is most convenient to do all of these steps on the same host
! 837: machine, since then you can do it all with a single invocation of GNU
! 838: CC. This requires a suitable cross-assembler and cross-linker. For
! 839: some targets, the GNU assembler and linker are available.
! 840:
! 841: Configuring a Cross-Compiler
! 842: ----------------------------
! 843:
1.1.1.3 root 844: To build GNU CC as a cross-compiler, you start out by running
1.1.1.4 root 845: `configure'. You must specify two different configurations, the host
1.1.1.3 root 846: and the target. Use the `--host=HOST' option for the host and
847: `--target=TARGET' to specify the target type. For example, here is how
848: to configure for a cross-compiler that runs on a hypothetical Intel 386
849: system and produces code for an HP 68030 system running BSD:
850:
851: configure --target=m68k-hp-bsd4.3 --host=i386-bozotheclone-bsd4.3
852:
1.1.1.6 ! root 853: Tools and Libraries for a Cross-Compiler
! 854: ----------------------------------------
! 855:
! 856: If you have a cross-assembler and cross-linker available, you should
! 857: install them now. Put them in the directory `/usr/local/TARGET/bin'.
! 858: Here is a table of the tools you should put in this directory:
! 859:
! 860: `as'
! 861: This should be the cross-assembler.
! 862:
! 863: `ld'
! 864: This should be the cross-linker.
! 865:
! 866: `ar'
! 867: This should be the cross-archiver: a program which can manipulate
! 868: archive files (linker libraries) in the target machine's format.
! 869:
! 870: `ranlib'
! 871: This should be a program to construct a symbol table in an archive
! 872: file.
! 873:
! 874: The installation of GNU CC will find these programs in that
! 875: directory, and copy or link them to the proper place to for the
! 876: cross-compiler to find them when run later.
! 877:
! 878: The easiest way to provide these files is to build the Binutils
! 879: package and GAS. Configure them with the same `--host' and `--target'
! 880: options that you use for configuring GNU CC, then build and install
! 881: them. They install their executables automatically into the proper
! 882: directory. Alas, they do not support all the targets that GNU CC
! 883: supports.
! 884:
! 885: If you want to install libraries to use with the cross-compiler,
! 886: such as a standard C library, put them in the directory
! 887: `/usr/local/TARGET/lib'; installation of GNU CC copies all all the
! 888: files in that subdirectory into the proper place for GNU CC to find
! 889: them and link with them. Here's an example of copying some libraries
! 890: from a target machine:
! 891:
! 892: ftp TARGET-MACHINE
! 893: lcd /usr/local/TARGET/lib
! 894: cd /lib
! 895: get libc.a
! 896: cd /usr/lib
! 897: get libg.a
! 898: get libm.a
! 899: quit
! 900:
! 901: The precise set of libraries you'll need, and their locations on the
! 902: target machine, vary depending on its operating system.
! 903:
! 904: Many targets require "start files" such as `crt0.o' and `crtn.o'
! 905: which are linked into each executable; these too should be placed in
! 906: `/usr/local/TARGET/lib'. There may be several alternatives for
! 907: `crt0.o', for use with profiling or other compilation options. Check
! 908: your target's definition of `STARTFILE_SPEC' to find out what start
! 909: files it uses. Here's an example of copying these files from a target
! 910: machine:
! 911:
! 912: ftp TARGET-MACHINE
! 913: lcd /usr/local/TARGET/lib
! 914: prompt
! 915: cd /lib
! 916: mget *crt*.o
! 917: cd /usr/lib
! 918: mget *crt*.o
! 919: quit
! 920:
! 921: `libgcc.a' and Cross-Compilers
! 922: ------------------------------
! 923:
! 924: Code compiled by GNU CC uses certain runtime support functions
! 925: implicitly. Some of these functions can be compiled successfully with
! 926: GNU CC itself, but a few cannot be. These problem functions are in the
! 927: source file `libgcc1.c'; the library made from them is called
! 928: `libgcc1.a'.
! 929:
! 930: When you build a native compiler, these functions are compiled with
! 931: some other compiler-the one that you use for bootstrapping GNU CC.
! 932: Presumably it knows how to open code these operations, or else knows how
! 933: to call the run-time emulation facilities that the machine comes with.
! 934: But this approach doesn't work for building a cross-compiler. The
! 935: compiler that you use for building knows about the host system, not the
! 936: target system.
! 937:
! 938: So, when you build a cross-compiler you have to supply a suitable
! 939: library `libgcc1.a' that does the job it is expected to do.
! 940:
! 941: To compile `libgcc1.c' with the cross-compiler itself does not work.
! 942: The functions in this file are supposed to implement arithmetic
! 943: operations that GNU CC does not know how to open code, for your target
! 944: machine. If these functions are compiled with GNU CC itself, they will
! 945: compile into infinite recursion.
! 946:
! 947: On any given target, most of these functions are not needed. If GNU
! 948: CC can open code an arithmetic operation, it will not call these
! 949: functions to perform the operation. It is possible that on your target
! 950: machine, none of these functions is needed. If so, you can supply an
! 951: empty library as `libgcc1.a'.
! 952:
! 953: Many targets need library support only for multiplication and
! 954: division. If you are linking with a library that contains functions for
! 955: multiplication and division, you can tell GNU CC to call them directly
! 956: by defining the macros `MULSI3_LIBCALL', and the like. These macros
! 957: need to be defined in the target description macro file. For some
! 958: targets, they are defined already. This may be sufficient to avoid the
! 959: need for libgcc1.a; if so, you can supply an empty library.
! 960:
! 961: Some targets do not have floating point instructions; they need other
! 962: functions in `libgcc1.a', which do floating arithmetic. Recent
! 963: versions of GNU CC have a file which emulates floating point. With a
! 964: certain amount of work, you should be able to construct a floating
! 965: point emulator that can be used as `libgcc1.a'. Perhaps future
! 966: versions will contain code to do this automatically and conveniently.
! 967: That depends on whether someone wants to implement it.
! 968:
! 969: If your target system has another C compiler, you can configure GNU
! 970: CC as a native compiler on that machine, build just `libgcc1.a' with
! 971: `make libgcc1.a' on that machine, and use the resulting file with the
! 972: cross-compiler. To do this, execute the following on the target
! 973: machine:
! 974:
! 975: cd TARGET-BUILD-DIR
! 976: configure --host=sparc --target=sun3
! 977: make libgcc1.a
! 978:
! 979: And then this on the host machine:
! 980:
! 981: ftp TARGET-MACHINE
! 982: binary
! 983: cd TARGET-BUILD-DIR
! 984: get libgcc1.a
! 985: quit
! 986:
! 987: Another way to provide the functions you need in `libgcc1.a' is to
! 988: define the appropriate `perform_...' macros for those functions. If
! 989: these definitions do not use the C arithmetic operators that they are
! 990: meant to implement, you should be able to compile them with the
! 991: cross-compiler you are building. (If these definitions already exist
! 992: for your target file, then you are all set.)
! 993:
! 994: To build `libgcc1.a' using the perform macros, use
! 995: `LIBGCC1=libgcc1.a OLDCC=./xgcc' when building the compiler.
! 996: Otherwise, you should place your replacement library under the name
! 997: `libgcc1.a' in the directory in which you will build the
! 998: cross-compiler, before you run `make'.
! 999:
! 1000: Cross-Compilers and Header Files
! 1001: --------------------------------
! 1002:
! 1003: If you are cross-compiling a standalone program or a program for an
! 1004: embedded system, then you may not need any header files except the few
! 1005: that are part of GNU CC (and those of your program). However, if you
! 1006: intend to link your program with a standard C library such as `libc.a',
! 1007: then you probably need to compile with the header files that go with
! 1008: the library you use.
! 1009:
! 1010: The GNU C compiler does not come with these files, because (1) they
! 1011: are system-specific, and (2) they belong in a C library, not in a
1.1.1.4 root 1012: compiler.
1013:
1.1.1.6 ! root 1014: If the GNU C library supports your target machine, then you can get
! 1015: the header files from there (assuming you actually use the GNU library
! 1016: when you link your program).
! 1017:
! 1018: If your target machine comes with a C compiler, it probably comes
! 1019: with suitable header files also. If you make these files accessible
! 1020: from the host machine, the cross-compiler can use them also.
! 1021:
! 1022: Otherwise, you're on your own in finding header files to use when
! 1023: cross-compiling.
! 1024:
! 1025: When you have found suitable header files, put them in
! 1026: `/usr/local/TARGET/include', before building the cross compiler. Then
! 1027: installation will run fixincludes properly and install the corrected
! 1028: versions of the header files where the compiler will use them.
! 1029:
! 1030: Provide the header files before you build the cross-compiler, because
! 1031: the build stage actually runs the cross-compiler to produce parts of
! 1032: `libgcc.a'. (These are the parts that *can* be compiled with GNU CC.)
! 1033: Some of them need suitable header files.
! 1034:
! 1035: Here's an example showing how to copy the header files from a target
! 1036: machine. On the target machine, do this:
! 1037:
! 1038: (cd /usr/include; tar cf - .) > tarfile
! 1039:
! 1040: Then, on the host machine, do this:
! 1041:
! 1042: ftp TARGET-MACHINE
! 1043: lcd /usr/local/TARGET/include
! 1044: get tarfile
! 1045: quit
! 1046: tar xf tarfile
! 1047:
! 1048: Actually Building the Cross-Compiler
! 1049: ------------------------------------
! 1050:
1.1.1.4 root 1051: Now you can proceed just as for compiling a single-machine compiler
1052: through the step of building stage 1. If you have not provided some
1053: sort of `libgcc1.a', then compilation will give up at the point where
1054: it needs that file, printing a suitable error message. If you do
1055: provide `libgcc1.a', then building the compiler will automatically
1056: compile and link a test program called `cross-test'; if you get errors
1057: in the linking, it means that not all of the necessary routines in
1058: `libgcc1.a' are available.
1059:
1.1.1.6 ! root 1060: If you are making a cross-compiler for an embedded system, and there
! 1061: is no `stdio.h' header for it, then the compilation of `enquire' will
! 1062: probably fail. The job of `enquire' is to run on the target machine
! 1063: and figure out by experiment the nature of its floating point
! 1064: representation. `enquire' records its findings in the header file
! 1065: `float.h'. If you can't produce this file by running `enquire' on the
! 1066: target machine, then you will need to come up with a suitable `float.h'
! 1067: in some other way (or else, avoid using it in your programs).
1.1.1.3 root 1068:
1069: Do not try to build stage 2 for a cross-compiler. It doesn't work to
1070: rebuild GNU CC as a cross-compiler using the cross-compiler, because
1071: that would produce a program that runs on the target machine, not on the
1072: host. For example, if you compile a 386-to-68030 cross-compiler with
1073: itself, the result will not be right either for the 386 (because it was
1074: compiled into 68030 code) or for the 68030 (because it was configured
1075: for a 386 as the host). If you want to compile GNU CC into 68030 code,
1076: whether you compile it on a 68030 or with a cross-compiler on a 386, you
1077: must specify a 68030 as the host when you configure it.
1078:
1.1.1.6 ! root 1079: To install the cross-compiler, use `make install', as usual.
! 1080:
1.1.1.5 root 1081: Installing on the HP Precision Architecture
1082: ===========================================
1.1.1.3 root 1083:
1084: There are two variants of this CPU, called 1.0 and 1.1, which have
1085: different machine descriptions. You must use the right one for your
1086: machine. All 7NN machines and 8N7 machines use 1.1, while all other
1087: 8NN machines use 1.0.
1088:
1089: The easiest way to handle this problem is to use `configure hpNNN'
1090: or `configure hpNNN-hpux', where NNN is the model number of the
1091: machine. Then `configure' will figure out if the machine is a 1.0 or
1092: 1.1. Use `uname -a' to find out the model number of your machine.
1093:
1094: `-g' does not work on HP-UX, since that system uses a peculiar
1.1.1.4 root 1095: debugging format which GNU CC does not know about. There are
1096: preliminary versions of GAS and GDB for the HP-PA which do work with
1097: GNU CC for debugging. You can get them by anonymous ftp from
1098: `jaguar.cs.utah.edu' `dist' subdirectory. You would need to install
1099: GAS in the file
1.1.1.3 root 1100:
1101: /usr/local/lib/gcc-lib/CONFIGURATION/GCCVERSION/as
1102:
1103: where CONFIGURATION is the configuration name (perhaps `hpNNN-hpux')
1.1.1.4 root 1104: and GCCVERSION is the GNU CC version number. Do this *before* starting
1105: the build process, otherwise you will get errors from the HPUX
1106: assembler while building `libgcc2.a'. The command
1.1.1.3 root 1107:
1.1.1.4 root 1108: make install-dir
1.1.1.3 root 1109:
1.1.1.4 root 1110: will create the necessary directory hierarchy so you can install GAS
1111: before building GCC.
1.1.1.3 root 1112:
1.1.1.4 root 1113: If you obtained GAS before October 6, 1992 it is highly recommended
1114: you get a new one to avoid several bugs which have been discovered
1115: recently.
1116:
1117: To enable debugging, configure GNU CC with the `--gas' option before
1118: building.
1.1.1.3 root 1119:
1.1.1.5 root 1120: It has been reported that GNU CC produces invalid assembly code for
1121: 1.1 machines running HP-UX 8.02 when using the HP assembler. Typically
1122: the errors look like this:
1123: as: bug.s @line#15 [err#1060]
1124: Argument 0 or 2 in FARG upper
1125: - lookahead = ARGW1=FR,RTNVAL=GR
1126: as: foo.s @line#28 [err#1060]
1127: Argument 0 or 2 in FARG upper
1128: - lookahead = ARGW1=FR
1129:
1130: You can check the version of HP-UX you are running by executing the
1.1.1.6 ! root 1131: command `uname -r'. If you are indeed running HP-UX 8.02 on a PA and
! 1132: using the HP assembler then configure GCC with "hpNNN-hpux8.02".
1.1.1.3 root 1133:
1.1 root 1134: Installing GNU CC on the Sun
1.1.1.5 root 1135: ============================
1136:
1137: On Solaris (version 2.1), do not use the linker or other tools in
1138: `/usr/ucb' to build GNU CC. Use `/usr/ccs/bin'.
1.1 root 1139:
1140: Make sure the environment variable `FLOAT_OPTION' is not set when
1141: you compile `libgcc.a'. If this option were set to `f68881' when
1142: `libgcc.a' is compiled, the resulting code would demand to be linked
1.1.1.3 root 1143: with a special startup file and would not link properly without special
1144: pains.
1.1 root 1145:
1.1.1.6 ! root 1146: The GNU compiler does not really support the Super SPARC processor
! 1147: that is used in SPARC Station 10 and similar class machines. You can
! 1148: get code that runs by specifying `sparc' as the cpu type; however, its
! 1149: performance is not very good, and may vary widely according to the
! 1150: compiler version and optimization options used. This is because the
! 1151: instruction scheduling parameters designed for the Sparc are not correct
! 1152: for the Super SPARC. Implementing scheduling parameters for the Super
! 1153: SPARC might be a good project for someone who is willing to learn a
! 1154: great deal about instruction scheduling in GNU CC.
! 1155:
1.1.1.3 root 1156: There is a bug in `alloca' in certain versions of the Sun library.
1.1 root 1157: To avoid this bug, install the binaries of GNU CC that were compiled by
1158: GNU CC. They use `alloca' as a built-in function and never the one in
1159: the library.
1160:
1161: Some versions of the Sun compiler crash when compiling GNU CC. The
1.1.1.3 root 1162: problem is a segmentation fault in cpp. This problem seems to be due to
1163: the bulk of data in the environment variables. You may be able to avoid
1164: it by using the following command to compile GNU CC with Sun CC:
1.1 root 1165:
1166: make CC="TERMCAP=x OBJS=x LIBFUNCS=x STAGESTUFF=x cc"
1167:
1168: Installing GNU CC on the 3b1
1.1.1.5 root 1169: ============================
1.1 root 1170:
1171: Installing GNU CC on the 3b1 is difficult if you do not already have
1172: GNU CC running, due to bugs in the installed C compiler. However, the
1173: following procedure might work. We are unable to test it.
1174:
1175: 1. Comment out the `#include "config.h"' line on line 37 of `cccp.c'
1176: and do `make cpp'. This makes a preliminary version of GNU cpp.
1177:
1178: 2. Save the old `/lib/cpp' and copy the preliminary GNU cpp to that
1179: file name.
1180:
1181: 3. Undo your change in `cccp.c', or reinstall the original version,
1182: and do `make cpp' again.
1183:
1184: 4. Copy this final version of GNU cpp into `/lib/cpp'.
1185:
1186: 5. Replace every occurrence of `obstack_free' in the file `tree.c'
1187: with `_obstack_free'.
1188:
1189: 6. Run `make' to get the first-stage GNU CC.
1190:
1191: 7. Reinstall the original version of `/lib/cpp'.
1192:
1.1.1.3 root 1193: 8. Now you can compile GNU CC with itself and install it in the normal
1194: fashion.
1.1 root 1195:
1196: Installing GNU CC on Unos
1.1.1.5 root 1197: =========================
1.1 root 1198:
1199: Use `configure unos' for building on Unos.
1200:
1201: The Unos assembler is named `casm' instead of `as'. For some
1202: strange reason linking `/bin/as' to `/bin/casm' changes the behavior,
1203: and does not work. So, when installing GNU CC, you should install the
1204: following script as `as' in the subdirectory where the passes of GCC
1205: are installed:
1206:
1207: #!/bin/sh
1208: casm $*
1209:
1.1.1.5 root 1210: The default Unos library is named `libunos.a' instead of `libc.a'.
1.1 root 1211: To allow GNU CC to function, either change all references to `-lc' in
1212: `gcc.c' to `-lunos' or link `/lib/libc.a' to `/lib/libunos.a'.
1213:
1.1.1.3 root 1214: When compiling GNU CC with the standard compiler, to overcome bugs in
1.1.1.5 root 1215: the support of `alloca', do not use `-O' when making stage 2. Then use
1.1.1.3 root 1216: the stage 2 compiler with `-O' to make the stage 3 compiler. This
1.1 root 1217: compiler will have the same characteristics as the usual stage 2
1218: compiler on other systems. Use it to make a stage 4 compiler and
1219: compare that with stage 3 to verify proper compilation.
1220:
1.1.1.3 root 1221: (Perhaps simply defining `ALLOCA' in `x-crds' as described in the
1222: comments there will make the above paragraph superfluous. Please
1223: inform us of whether this works.)
1224:
1.1 root 1225: Unos uses memory segmentation instead of demand paging, so you will
1226: need a lot of memory. 5 Mb is barely enough if no other tasks are
1.1.1.5 root 1227: running. If linking `cc1' fails, try putting the object files into a
1.1 root 1228: library and linking from that library.
1229:
1230: Installing GNU CC on VMS
1.1.1.5 root 1231: ========================
1.1 root 1232:
1233: The VMS version of GNU CC is distributed in a backup saveset
1234: containing both source code and precompiled binaries.
1235:
1236: To install the `gcc' command so you can use the compiler easily, in
1.1.1.3 root 1237: the same manner as you use the VMS C compiler, you must install the VMS
1238: CLD file for GNU CC as follows:
1.1 root 1239:
1240: 1. Define the VMS logical names `GNU_CC' and `GNU_CC_INCLUDE' to
1.1.1.4 root 1241: point to the directories where the GNU CC executables
1242: (`gcc-cpp.exe', `gcc-cc1.exe', etc.) and the C include files are
1243: kept respectively. This should be done with the commands:
1.1 root 1244:
1.1.1.2 root 1245: $ assign /system /translation=concealed -
1246: disk:[gcc.] gnu_cc
1247: $ assign /system /translation=concealed -
1248: disk:[gcc.include.] gnu_cc_include
1.1 root 1249:
1.1.1.3 root 1250: with the appropriate disk and directory names. These commands can
1251: be placed in your system startup file so they will be executed
1252: whenever the machine is rebooted. You may, if you choose, do this
1253: via the `GCC_INSTALL.COM' script in the `[GCC]' directory.
1.1 root 1254:
1255: 2. Install the `GCC' command with the command line:
1256:
1.1.1.2 root 1257: $ set command /table=sys$common:[syslib]dcltables -
1258: /output=sys$common:[syslib]dcltables gnu_cc:[000000]gcc
1259: $ install replace sys$common:[syslib]dcltables
1.1 root 1260:
1261: 3. To install the help file, do the following:
1262:
1.1.1.4 root 1263: $ library/help sys$library:helplib.hlb gcc.hlp
1.1 root 1264:
1265: Now you can invoke the compiler with a command like `gcc /verbose
1266: file.c', which is equivalent to the command `gcc -v -c file.c' in
1267: Unix.
1268:
1269: If you wish to use GNU C++ you must first install GNU CC, and then
1270: perform the following steps:
1271:
1272: 1. Define the VMS logical name `GNU_GXX_INCLUDE' to point to the
1273: directory where the preprocessor will search for the C++ header
1.1.1.5 root 1274: files. This can be done with the command:
1.1 root 1275:
1.1.1.2 root 1276: $ assign /system /translation=concealed -
1277: disk:[gcc.gxx_include.] gnu_gxx_include
1.1 root 1278:
1.1.1.3 root 1279: with the appropriate disk and directory name. If you are going to
1280: be using libg++, this is where the libg++ install procedure will
1281: install the libg++ header files.
1.1 root 1282:
1283: 2. Obtain the file `gcc-cc1plus.exe', and place this in the same
1284: directory that `gcc-cc1.exe' is kept.
1285:
1.1.1.3 root 1286: The GNU C++ compiler can be invoked with a command like `gcc /plus
1287: /verbose file.cc', which is equivalent to the command `g++ -v -c
1288: file.cc' in Unix.
1.1 root 1289:
1290: We try to put corresponding binaries and sources on the VMS
1291: distribution tape. But sometimes the binaries will be from an older
1.1.1.4 root 1292: version than the sources, because we don't always have time to update
1.1 root 1293: them. (Use the `/version' option to determine the version number of
1294: the binaries and compare it with the source file `version.c' to tell
1.1.1.3 root 1295: whether this is so.) In this case, you should use the binaries you get
1296: to recompile the sources. If you must recompile, here is how:
1.1 root 1297:
1.1.1.5 root 1298: 1. Execute the command procedure `vmsconfig.com' to set up the files
1299: `tm.h', `config.h', `aux-output.c', and `md.', and to create files
1300: `tconfig.h' and `hconfig.h'. This procedure also creates several
1301: linker option files used by `make-cc1.com' and a data file used by
1302: `make-l2.com'.
1.1.1.4 root 1303:
1304: $ @vmsconfig.com
1.1 root 1305:
1306: 2. Setup the logical names and command tables as defined above. In
1307: addition, define the VMS logical name `GNU_BISON' to point at the
1308: to the directories where the Bison executable is kept. This
1309: should be done with the command:
1310:
1.1.1.2 root 1311: $ assign /system /translation=concealed -
1312: disk:[bison.] gnu_bison
1.1 root 1313:
1.1.1.3 root 1314: You may, if you choose, use the `INSTALL_BISON.COM' script in the
1315: `[BISON]' directory.
1.1 root 1316:
1317: 3. Install the `BISON' command with the command line:
1318:
1.1.1.2 root 1319: $ set command /table=sys$common:[syslib]dcltables -
1320: /output=sys$common:[syslib]dcltables -
1321: gnu_bison:[000000]bison
1322: $ install replace sys$common:[syslib]dcltables
1.1 root 1323:
1.1.1.5 root 1324: 4. Type `@make-gcc' to recompile everything (alternatively, submit
1325: the file `make-gcc.com' to a batch queue). If you wish to build
1326: the GNU C++ compiler as well as the GNU CC compiler, you must
1.1.1.3 root 1327: first edit `make-gcc.com' and follow the instructions that appear
1328: in the comments.
1.1 root 1329:
1.1.1.2 root 1330: 5. In order to use GCC, you need a library of functions which GCC
1331: compiled code will call to perform certain tasks, and these
1332: functions are defined in the file `libgcc2.c'. To compile this
1333: you should use the command procedure `make-l2.com', which will
1.1.1.5 root 1334: generate the library `libgcc2.olb'. `libgcc2.olb' should be built
1.1.1.3 root 1335: using the compiler built from the same distribution that
1.1.1.2 root 1336: `libgcc2.c' came from, and `make-gcc.com' will automatically do
1337: all of this for you.
1338:
1.1.1.3 root 1339: To install the library, use the following commands:
1.1.1.2 root 1340:
1.1.1.4 root 1341: $ library gnu_cc:[000000]gcclib/delete=(new,eprintf)
1.1.1.5 root 1342: $ library gnu_cc:[000000]gcclib/delete=L_*
1.1.1.4 root 1343: $ library libgcc2/extract=*/output=libgcc2.obj
1344: $ library gnu_cc:[000000]gcclib libgcc2.obj
1.1.1.2 root 1345:
1.1.1.3 root 1346: The first command simply removes old modules that will be replaced
1.1.1.5 root 1347: with modules from `libgcc2' under different module names. The
1348: modules `new' and `eprintf' may not actually be present in your
1349: `gcclib.olb'--if the VMS librarian complains about those modules
1350: not being present, simply ignore the message and continue on with
1351: the next command. The second command removes the modules that
1352: came from the previous version of the library `libgcc2.c'.
1.1.1.3 root 1353:
1354: Whenever you update the compiler on your system, you should also
1355: update the library with the above procedure.
1356:
1.1.1.4 root 1357: 6. You may wish to build GCC in such a way that no files are written
1.1.1.3 root 1358: to the directory where the source files reside. An example would
1359: be the when the source files are on a read-only disk. In these
1360: cases, execute the following DCL commands (substituting your
1361: actual path names):
1362:
1.1.1.4 root 1363: $ assign dua0:[gcc.build_dir.]/translation=concealed, -
1364: dua1:[gcc.source_dir.]/translation=concealed gcc_build
1.1.1.3 root 1365: $ set default gcc_build:[000000]
1366:
1.1.1.5 root 1367: where the directory `dua1:[gcc.source_dir]' contains the source
1368: code, and the directory `dua0:[gcc.build_dir]' is meant to contain
1369: all of the generated object files and executables. Once you have
1370: done this, you can proceed building GCC as described above. (Keep
1371: in mind that `gcc_build' is a rooted logical name, and thus the
1372: device names in each element of the search list must be an actual
1373: physical device name rather than another rooted logical name).
1.1.1.3 root 1374:
1.1.1.4 root 1375: 7. *If you are building GNU CC with a previous version of GNU CC, you
1.1.1.3 root 1376: also should check to see that you have the newest version of the
1377: assembler*. In particular, GNU CC version 2 treats global constant
1378: variables slightly differently from GNU CC version 1, and GAS
1379: version 1.38.1 does not have the patches required to work with GCC
1.1.1.5 root 1380: version 2. If you use GAS 1.38.1, then `extern const' variables
1.1.1.3 root 1381: will not have the read-only bit set, and the linker will generate
1382: warning messages about mismatched psect attributes for these
1383: variables. These warning messages are merely a nuisance, and can
1384: safely be ignored.
1.1 root 1385:
1.1.1.3 root 1386: If you are compiling with a version of GNU CC older than 1.33,
1.1 root 1387: specify `/DEFINE=("inline=")' as an option in all the
1388: compilations. This requires editing all the `gcc' commands in
1.1.1.5 root 1389: `make-cc1.com'. (The older versions had problems supporting
1.1 root 1390: `inline'.) Once you have a working 1.33 or newer GNU CC, you can
1391: change this file back.
1392:
1.1.1.4 root 1393: 8. If you want to build GNU CC with the VAX C compiler, you will need
1394: to make minor changes in `make-cccp.com' and `make-cc1.com' to
1395: choose alternate definitions of `CC', `CFLAGS', and `LIBS'. See
1396: comments in those files. However, you must also have a working
1397: version of the GNU assembler (GNU as, aka GAS) as it is used as
1398: the back-end for GNU CC to produce binary object modules and is
1399: not included in the GNU CC sources. GAS is also needed to compile
1400: `libgcc2' in order to build `gcclib' (see above); `make-l2.com'
1401: expects to be able to find it operational in
1402: `gnu_cc:[000000]gnu-as.exe'.
1403:
1404: To use GNU CC on VMS, you need the VMS driver programs `gcc.exe',
1405: `gcc.com', and `gcc.cld'. They are distributed with the VMS
1406: binaries (`gcc-vms') rather than the GNU CC sources. GAS is also
1407: included in `gcc-vms', as is Bison.
1408:
1409: Once you have successfully built GNU CC with VAX C, you should use
1410: the resulting compiler to rebuild itself. Before doing this, be
1411: sure to restore the `CC', `CFLAGS', and `LIBS' definitions in
1412: `make-cccp.com' and `make-cc1.com'. The second generation
1413: compiler will be able to take advantage of many optimizations that
1414: must be suppressed when building with other compilers.
1415:
1.1 root 1416: Under previous versions of GNU CC, the generated code would
1.1.1.4 root 1417: occasionally give strange results when linked with the sharable
1.1.1.5 root 1418: `VAXCRTL' library. Now this should work.
1.1 root 1419:
1420: Even with this version, however, GNU CC itself should not be linked
1.1.1.4 root 1421: with the sharable `VAXCRTL'. The version of `qsort' in `VAXCRTL' has a
1422: bug (known to be present in VMS versions V4.6 through V5.5) which
1423: causes the compiler to fail.
1.1 root 1424:
1.1.1.5 root 1425: The executables are generated by `make-cc1.com' and `make-cccp.com'
1426: use the object library version of `VAXCRTL' in order to make use of the
1427: `qsort' routine in `gcclib.olb'. If you wish to link the compiler
1428: executables with the shareable image version of `VAXCRTL', you should
1429: edit the file `tm.h' (created by `vmsconfig.com') to define the macro
1430: `QSORT_WORKAROUND'.
1.1.1.4 root 1431:
1432: `QSORT_WORKAROUND' is always defined when GNU CC is compiled with
1433: VAX C, to avoid a problem in case `gcclib.olb' is not yet available.
1434:
1435: Installing GNU CC on the WE32K
1.1.1.5 root 1436: ==============================
1.1.1.4 root 1437:
1438: These computers are also known as the 3b2, 3b5, 3b20 and other
1439: similar names. (However, the 3b1 is actually a 68000; see *Note 3b1
1440: Install::.)
1441:
1442: Don't use `-g' when compiling with the system's compiler. The
1443: system's linker seems to be unable to handle such a large program with
1444: debugging information.
1445:
1446: The system's compiler runs out of capacity when compiling `stmt.c'
1447: in GNU CC. You can work around this by building `cpp' in GNU CC first,
1448: then use that instead of the system's preprocessor with the system's C
1449: compiler to compile `stmt.c'. Here is how:
1450:
1451: mv /lib/cpp /lib/cpp.att
1452: cp cpp /lib/cpp.gnu
1.1.1.6 ! root 1453: echo '/lib/cpp.gnu -traditional ${1+"$@"}' > /lib/cpp
1.1.1.4 root 1454: chmod +x /lib/cpp
1455:
1456: The system's compiler produces bad code for some of the GNU CC
1457: optimization files. So you must build the stage 2 compiler without
1.1.1.5 root 1458: optimization. Then build a stage 3 compiler with optimization. That
1.1.1.4 root 1459: executable should work. Here are the necessary commands:
1460:
1461: make LANGUAGES=c CC=stage1/xgcc CFLAGS="-Bstage1/ -g"
1462: make stage2
1463: make CC=stage2/xgcc CFLAGS="-Bstage2/ -g -O"
1464:
1465: You may need to raise the ULIMIT setting to build a C++ compiler, as
1466: the file `cc1plus' is larger than one megabyte.
1467:
1468: Installing GNU CC on the MIPS
1.1.1.5 root 1469: =============================
1.1.1.4 root 1470:
1.1.1.5 root 1471: See *Note Installation:: about whether to use either of the options
1472: `--with-stabs' or `--with-gnu-as'.
1.1.1.4 root 1473:
1474: The MIPS C compiler needs to be told to increase its table size for
1475: switch statements with the `-Wf,-XNg1500' option in order to compile
1476: `cp-parse.c'. If you use the `-O2' optimization option, you also need
1.1.1.5 root 1477: to use `-Olimit 3000'. Both of these options are automatically
1.1.1.4 root 1478: generated in the `Makefile' that the shell script `configure' builds.
1479: If you override the `CC' make variable and use the MIPS compilers, you
1480: may need to add `-Wf,-XNg1500 -Olimit 3000'.
1481:
1482: MIPS computers running RISC-OS can support four different
1483: personalities: default, BSD 4.3, System V.3, and System V.4 (older
1484: versions of RISC-OS don't support V.4). To configure GCC for these
1485: platforms use the following configurations:
1486:
1487: `mips-mips-riscos`rev''
1488: Default configuration for RISC-OS, revision `rev'.
1489:
1490: `mips-mips-riscos`rev'bsd'
1491: BSD 4.3 configuration for RISC-OS, revision `rev'.
1492:
1493: `mips-mips-riscos`rev'sysv4'
1494: System V.4 configuration for RISC-OS, revision `rev'.
1495:
1496: `mips-mips-riscos`rev'sysv'
1497: System V.3 configuration for RISC-OS, revision `rev'.
1498:
1499: The revision `rev' mentioned above is the revision of RISC-OS to
1500: use. You must reconfigure GCC when going from a RISC-OS revision 4 to
1501: RISC-OS revision 5. This has the effect of avoiding a linker bug.
1502:
1503: DECstations can support three different personalities: Ultrix, DEC
1504: OSF/1, and OSF/rose. To configure GCC for these platforms use the
1505: following configurations:
1506:
1507: `decstation-ultrix'
1508: Ultrix configuration.
1509:
1510: `decstation-osf1'
1511: Dec's version of OSF/1.
1512:
1513: `decstation-osfrose'
1514: Open Software Foundation reference port of OSF/1 which uses the
1515: OSF/rose object file format instead of ECOFF. Normally, you would
1516: not select this configuration.
1.1.1.2 root 1517:
1.1.1.5 root 1518: On Irix version 4.0.5F, and perhaps on some other versions as well,
1519: there is an assembler bug that reorders instructions incorrectly. To
1520: work around it, specify the target configuration `mips-sgi-irix4loser'.
1521: This configuration inhibits assembler optimization.
1522:
1523: You can turn off assembler optimization in a compiler configured with
1524: target `mips-sgi-irix4' using the `-noasmopt' option. This compiler
1525: option passes the option `-O0' to the assembler, to inhibit reordering.
1526:
1527: The `-noasmopt' option can be useful for testing whether a problem
1528: is due to erroneous assembler reordering. Even if a problem does not go
1529: away with `-noasmopt', it may still be due to assembler
1530: reordering--perhaps GNU CC itself was miscompiled as a result.
1531:
1532: We know this is inconvenient, but it's the best that can be done at
1533: the last minute.
1534:
1535: `collect2'
1536: ==========
1537:
1538: Many target systems do not have support in the assembler and linker
1539: for "constructors"--initialization functions to be called before the
1540: official "start" of `main'. On such systems, GNU CC uses a utility
1541: called `collect2' to arrange to call these functions at start time.
1542:
1543: The program `collect2' works by linking the program once and looking
1544: through the linker output file for symbols with particular names
1545: indicating they are constructor functions. If it finds any, it creates
1546: a new temporary `.c' file containing a table of them, compiles it, and
1547: links the program a second time including that file.
1548:
1549: The actual calls to the constructors are carried out by a subroutine
1550: called `__main', which is called (automatically) at the beginning of
1551: the body of `main' (provided `main' was compiled with GNU CC).
1552:
1553: The program `collect2' is installed as `ld' in the directory where
1554: the passes of the compiler are installed. When `collect2' needs to
1555: find the *real* `ld', it tries the following file names:
1556:
1557: * `gld' in the directories listed in the compiler's search
1558: directories.
1559:
1560: * `gld' in the directories listed in the environment variable `PATH'.
1561:
1562: * `real-ld' in the compiler's search directories.
1563:
1564: * `real-ld' in `PATH'.
1565:
1566: * `ld' in `PATH'.
1567:
1568: "The compiler's search directories" means all the directories where
1569: `gcc' searches for passes of the compiler. This includes directories
1570: that you specify with `-B'.
1571:
1.1.1.6 ! root 1572: Cross-compilers search a little differently:
1.1.1.5 root 1573:
1574: * `gld' in the compiler's search directories.
1575:
1576: * `TARGET-gld' in `PATH'.
1577:
1578: * `real-ld' in the compiler's search directories.
1579:
1580: * `TARGET-real-ld' in `PATH'.
1581:
1582: * `TARGET-ld' in `PATH'.
1583:
1584: `collect2' does not search for `ld' using the compiler's search
1585: directories, because if it did, it would find itself--not the real
1586: `ld'--and this could lead to infinite recursion. However, the
1587: directory where `collect2' is installed might happen to be in `PATH'.
1588: That could lead `collect2' to invoke itself anyway. when looking for
1589: `ld'.
1590:
1591: To prevent this, `collect2' explicitly avoids running `ld' using the
1592: file name under which `collect2' itself was invoked. In fact, it
1593: remembers up to two such names--in case one copy of `collect2' finds
1594: another copy (or version) of `collect2' installed as `ld' in a second
1595: place in the search path.
1596:
1597: If two file names to avoid are not sufficient, you may still
1598: encounter an infinite recursion of `collect2' processes. When this
1599: happens. check all the files installed as `ld' in any of the
1600: directories searched, and straighten out the situation.
1601:
1602: (In a future version, we will probably change `collect2' to avoid
1603: any reinvocation of a file from which any parent `collect2' was run.)
1604:
1.1.1.6 ! root 1605: Standard Header File Directories
! 1606: ================================
! 1607:
! 1608: `GCC_INCLUDE_DIR' means the same thing for native and cross. It is
! 1609: where GNU CC stores its private include files, and also where GNU CC
! 1610: stores the fixed include files. A cross compiled GNU CC runs
! 1611: `fixincludes' on the header files in `$(tooldir)/include'. (If the
! 1612: cross compilation header files need to be fixed, they must be installed
! 1613: before GNU CC is built. If the cross compilation header files are
! 1614: already suitable for ANSI C and GNU CC, nothing special need be done).
! 1615:
! 1616: `GPLUS_INCLUDE_DIR' means the same thing for native and cross. It
! 1617: is where `g++' looks first for header files. `libg++' installs only
! 1618: target independent header files in that directory.
! 1619:
! 1620: `LOCAL_INCLUDE_DIR' is used only for a native compiler. It is
! 1621: normally `/usr/local/include'. GNU CC searches this directory so that
! 1622: users can install header files in `/usr/local/include'.
! 1623:
! 1624: `CROSS_INCLUDE_DIR' is used only for a cross compiler. GNU CC
! 1625: doesn't install anything there.
! 1626:
! 1627: `TOOL_INCLUDE_DIR' is used for both native and cross compilers. It
! 1628: is the place for other packages to install header files that GNU CC will
! 1629: use. For a cross-compiler, this is the equivalent of `/usr/include'.
! 1630: When you build a cross-compiler, `fixincludes' processes any header
! 1631: files in this directory.
! 1632:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.