|
|
1.1 root 1: This is Info file gcc.info, produced by Makeinfo-1.43 from the input
2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
6: Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc.
7:
8: Permission is granted to make and distribute verbatim copies of
9: this manual provided the copyright notice and this permission notice
10: are preserved on all copies.
11:
12: Permission is granted to copy and distribute modified versions of
13: this manual under the conditions for verbatim copying, provided also
14: that the section entitled "GNU General Public License" is included
15: exactly as in the original, and provided that the entire resulting
16: derived work is distributed under the terms of a permission notice
17: identical to this one.
18:
19: Permission is granted to copy and distribute translations of this
20: manual into another language, under the above conditions for modified
21: versions, except that the section entitled "GNU General Public
22: License" and this permission notice may be included in translations
23: approved by the Free Software Foundation instead of in the original
24: English.
25:
26:
27: File: gcc.info, Node: M88K Options, Next: RS/6000 Options, Prev: AMD29K Options, Up: Submodel Options
28:
29: M88K Options
30: ------------
31:
32: These `-m' options are defined for Motorola 88K architectures:
33:
34: `-m88000'
35: Generate code that works well on both the m88100 and the m88110.
36:
37: `-m88100'
38: Generate code tha Generate code that works best for the m88100,
39: but that also runs on the m88110.
40:
41: `-m88110'
42: Generate code that works best for the m88110, and may not run on
43: the m88100.
44:
45: `-midentify-revision'
46: Include an `ident' directive in the assembler output recording the
47: source file name, compiler name and version, timestamp, and
48: compilation flags used.
49:
50: `-mno-underscores'
51: In assembler output, emit symbol names without adding an
52: underscore character at the beginning of each name. The default
53: is to use an underscore as prefix on each name.
54:
55: `-mocs-debug-info'
56: `-mno-ocs-debug-info'
57: Include (or omit) additional debugging information (about
58: registers used in each stack frame) as specified in the 88open
59: Object Compatibility Standard, "OCS". This extra information
60: allows debugging of code that has had the frame pointer
61: eliminated. The default for DG/UX, SVr4, and Delta 88 SVr3.2 is
62: to include this information; other 88k configurations omit this
63: information by default.
64:
65: `-mocs-frame-position'
66: When emitting COFF debugging information for automatic variables
67: and parameters stored on the stack, use the offset from the
68: canonical frame address, which is the stack pointer (register 31)
69: on entry to the function. The DG/UX, SVr4, Delta88 SVr3.2, and
70: BCS configurations use `-mocs-frame-position'; other 88k
71: configurations have the default `-mno-ocs-frame-position'.
72:
73: `-mno-ocs-frame-position'
74: When emitting COFF debugging information for automatic variables
75: and parameters stored on the stack, use the offset from the frame
76: pointer register (register 30). When this option is in effect,
77: the frame pointer is not eliminated when debugging information is
78: selected by the -g switch.
79:
80: `-moptimize-arg-area'
81: `-mno-optimize-arg-area'
82: Control how to store function arguments in stack frames.
83: `-moptimize-arg-area' saves space, but was ruled illegal by
84: 88open. `-mno-optimize-arg-area' conforms to the 88open
85: standards. By default GNU CC does not optimize the argument area.
86:
87: `-mshort-data-NUM'
88: Generate smaller data references by making them relative to `r0',
89: which allows loading a value using a single instruction (rather
90: than the usual two). You control which data references are
91: affected by specifying NUM with this option. For example, if you
92: specify `-mshort-data-512', then the data references affected are
93: those involving displacements of less than 512 bytes.
94: `-mshort-data-NUM' is not effective for NUM greater than 64K.
95:
96: `-msvr4'
97: `-msvr3'
98: Turn on (`-msvr4') or off (`-msvr3') compiler extensions related
99: to System V release 4 (SVr4). This controls the following:
100:
101: 1. Which variant of the assembler syntax to emit (which you can
102: select independently using `-mversion-03.00').
103:
104: 2. `-msvr4' makes the C preprocessor recognize `#pragma weak'
105: that is used on System V release 4.
106:
107: 3. `-msvr4' makes GNU CC issue additional declaration
108: directives used in SVr4.
109:
110: `-msvr3' is the default for all m88K configurations except the
111: SVr4 configuration.
112:
113: `-mversion-03.00'
114: In the DG/UX configuration, there are two flavors of SVr4. This
115: option modifies `-msvr4' to select whether the hybrid-COFF or
116: real-ELF flavor is used. All other configurations ignore this
117: option.
118:
119: `-mno-check-zero-division'
120: `-mcheck-zero-division'
121: Early models of the 88K architecture had problems with division
122: by zero; in particular, many of them didn't trap. Use these
123: options to avoid including (or to include explicitly) additional
124: code to detect division by zero and signal an exception. All GNU
125: CC configurations for the 88K use `-mcheck-zero-division' by
126: default.
127:
128: `-muse-div-instruction'
129: Do not emit code to check both the divisor and dividend when doing
130: signed integer division to see if either is negative, and adjust
131: the signs so the divide is done using non-negative numbers.
132: Instead, rely on the operating system to calculate the correct
133: value when the `div' instruction traps. This results in
134: different behavior when the most negative number is divided by
135: -1, but is useful when most or all signed integer divisions are
136: done with positive numbers.
137:
138: `-mtrap-large-shift'
139: `-mhandle-large-shift'
140: Include code to detect bit-shifts of more than 31 bits;
141: respectively, trap such shifts or emit code to handle them
142: properly. By default GNU CC makes no special provision for large
143: bit shifts.
144:
145: `-mwarn-passed-structs'
146: Warn when a function passes a struct as an argument or result.
147: Structure-passing conventions have changed during the evolution
148: of the C language, and are often the source of portability
149: problems. By default, GNU CC issues no such warning.
150:
151:
152: File: gcc.info, Node: RS/6000 Options, Next: RT Options, Prev: M88K Options, Up: Submodel Options
153:
154: IBM RS/6000 Options
155: -------------------
156:
157: Only one pair of `-m' options is defined for the IBM RS/6000:
158:
159: `-mfp-in-toc'
160: `-mno-fp-in-toc'
161: Control whether or not floating-point constants go in the Table of
162: Contents (TOC), a table of all global variable and function
163: addresses. By default GNU CC puts floating-point constants
164: there; if the TOC overflows, `-mno-fp-in-toc' will reduce the
165: size of the TOC, which may avoid the overflow.
166:
167:
168: File: gcc.info, Node: RT Options, Next: MIPS Options, Prev: RS/6000 Options, Up: Submodel Options
169:
170: IBM RT Options
171: --------------
172:
173: These `-m' options are defined for the IBM RT PC:
174:
175: `-min-line-mul'
176: Use an in-line code sequence for integer multiplies. This is the
177: default.
178:
179: `-mcall-lib-mul'
180: Call `lmul$$' for integer multiples.
181:
182: `-mfull-fp-blocks'
183: Generate full-size floating point data blocks, including the
184: minimum amount of scratch space recommended by IBM. This is the
185: default.
186:
187: `-mminimum-fp-blocks'
188: Do not include extra scratch space in floating point data blocks.
189: This results in smaller code, but slower execution, since
190: scratch space must be allocated dynamically.
191:
192: `-mfp-arg-in-fpregs'
193: Use a calling sequence incompatible with the IBM calling
194: convention in which floating point arguments are passed in
195: floating point registers. Note that `varargs.h' and `stdargs.h'
196: will not work with floating point operands if this option is
197: specified.
198:
199: `-mfp-arg-in-gregs'
200: Use the normal calling convention for floating point arguments.
201: This is the default.
202:
203: `-mhc-struct-return'
204: Return structures of more than one word in memory, rather than in
205: a register. This provides compatibility with the MetaWare HighC
206: (hc) compiler. Use `-fpcc-struct-return' for compatibility with
207: the Portable C Compiler (pcc).
208:
209: `-mnohc-struct-return'
210: Return some structures of more than one word in registers, when
211: convenient. This is the default. For compatibility with the
212: IBM-supplied compilers, use either `-fpcc-struct-return' or
213: `-mhc-struct-return'.
214:
215:
216: File: gcc.info, Node: MIPS Options, Prev: RT Options, Up: Submodel Options
217:
218: MIPS Options
219: ------------
220:
221: These `-m' options are defined for the MIPS family of computers:
222:
223: `-mcpu=CPU TYPE'
224: Assume the defaults for the machine type CPU TYPE when scheduling
225: insturctions. The default CPU TYPE is `default', which picks the
226: longest cycles times for any of the machines, in order that the
227: code run at reasonable rates on all MIPS cpu's. Other choices
228: for CPU TYPE are `r2000', `r3000', `r4000', and `r6000'. While
229: picking a specific CPU TYPE will schedule things appropriately
230: for that particular chip, the compiler will not generate any code
231: that does not meet level 1 of the MIPS ISA (instruction set
232: architecture) without the `-mips2' or `-mips3' switches being
233: used.
234:
235: `-mips2'
236: Issue instructions from level 2 of the MIPS ISA (branch likely,
237: square root instructions). The `-mcpu=r4000' or `-mcpu=r6000'
238: switch must be used in conjuction with `-mips2'.
239:
240: `-mips3'
241: Issue instructions from level 3 of the MIPS ISA (64 bit
242: instructions). You must use the `-mcpu=r4000' switch along with
243: `-mips3'.
244:
245: `-mint64'
246: `-mlong64'
247: `-mlonglong128'
248: These options don't work at present.
249:
250: `-mmips-as'
251: Generate code for the MIPS assembler, and invoke `mips-tfile' to
252: add normal debug information. This is the default for all
253: platforms except for the OSF/1 reference platform, using the
254: OSF/rose object format. If the either of the `-gstabs' or
255: `-gstabs+' switches are used, the `mips-tfile' program will
256: encapsulate the stabs within MIPS ECOFF.
257:
258: `-mgas'
259: Generate code for the GNU assembler. This is the default on the
260: OSF/1 reference platform, using the OSF/rose object format.
261:
262: `-mrnames'
263: `-mno-rnames'
264: The `-mrnames' switch says to output code using the MIPS software
265: names for the registers, instead of the hardware names (ie, A0
266: instead of $4). The GNU assembler does not support the
267: `-mrnames' switch, and the MIPS assembler will be instructed to
268: run the MIPS C preprocessor over the source file. The
269: `-mno-rnames' switch is default.
270:
271: `-mgpopt'
272: `-mno-gpopt'
273: The `-mgpopt' switch says to write all of the data declarations
274: before the instructions in the text section, to all the MIPS
275: assembler to generate one word memory references instead of using
276: two words for short global or static data items. This is on by
277: default if optimization is selected.
278:
279: `-mstats'
280: `-mno-stats'
281: For each non-inline function processed, the `-mstats' switch
282: causes the compiler to emit one line to the standard error file to
283: print statistics about the program (number of registers saved,
284: stack size, etc.).
285:
286: `-mmemcpy'
287: `-mno-memcpy'
288: The `-mmemcpy' switch makes all block moves call the appropriate
289: string function (`memcpy' or `bcopy') instead of possibly
290: generating inline code.
291:
292: `-mmips-tfile'
293: `-mno-mips-tfile'
294: The `-mno-mips-tfile' switch causes the compiler not postprocess
295: the object file with the `mips-tfile' program, after the MIPS
296: assembler has generated it to add debug support. If `mips-tfile'
297: is not run, then no local variables will be available to the
298: debugger. In addition, `stage2' and `stage3' objects will have
299: the temporary file names passed to the assembler embedded in the
300: object file, which means the objects will not compare the same.
301:
302: `-msoft-float'
303: Generate output containing library calls for floating point.
304: *Warning:* the requisite libraries are not part of GNU CC.
305: Normally the facilities of the machine's usual C compiler are
306: used, but this can't be done directly in cross-compilation. You
307: must make your own arrangements to provide suitable library
308: functions for cross-compilation.
309:
310: `-mhard-float'
311: Generate output containing floating point instructions. This is
312: the default if you use the unmodified sources.
313:
314: `-mfp64'
315: Assume that the FR bit in the status word is on, and that there
316: are 32 64-bit floating point registers, instead of 32 32-bit
317: floating point registers. You must also specify the
318: `-mcpu=r4000' and `-mips3' switches.
319:
320: `-mfp32'
321: Assume that there are 32 32-bit floating point registers. This
322: is the default.
323:
324: `-mabicalls'
325: `-mno-abicalls'
326: Emit the `.abicalls', `.cpload', and `.cprestore' pseudo
327: operations that some System V.4 ports use for position
328: independent code.
329:
330: `-mhalf-pic'
331: `-mno-half-pic'
332: Put pointers to extern references into the data section and load
333: them up, rather than put the references in the text section.
334: These options do not work at present.
335:
336: `-G NUM'
337: Put global and static items less than or equal to NUM bytes into
338: the small data or bss sections instead of the normal data or bss
339: section. This allows the assembler to emit one word memory
340: reference instructions based on the global pointer (GP or $28),
341: instead of the normal two words used. By default, NUM is 8 when
342: the MIPS assembler is used, and 0 when the GNU assembler is used.
343: The `-G NUM' switch is also passed to the assembler and linker.
344: All modules should be compiled with the same `-G NUM' value.
345:
346: These options are defined by the macro `TARGET_SWITCHES' in the
347: machine description. The default for the options is also defined by
348: that macro, which enables you to change the defaults.
349:
350:
351: File: gcc.info, Node: Code Gen Options, Next: Environment Variables, Prev: Submodel Options, Up: Invoking GCC
352:
353: Options for Code Generation Conventions
354: =======================================
355:
356: These machine-independent options control the interface conventions
357: used in code generation.
358:
359: Most of them have both positive and negative forms; the negative
360: form of `-ffoo' would be `-fno-foo'. In the table below, only one of
361: the forms is listed--the one which is not the default. You can figure
362: out the other form by either removing `no-' or adding it.
363:
364: `-fpcc-struct-return'
365: Use the same convention for returning `struct' and `union' values
366: that is used by the usual C compiler on your system. This
367: convention is less efficient for small structures, and on many
368: machines it fails to be reentrant; but it has the advantage of
369: allowing intercallability between GNU CC-compiled code and
370: PCC-compiled code.
371:
372: `-fshort-enums'
373: Allocate to an `enum' type only as many bytes as it needs for the
374: declared range of possible values. Specifically, the `enum' type
375: will be equivalent to the smallest integer type which has enough
376: room.
377:
378: `-fshort-double'
379: Use the same size for `double' as for `float'.
380:
381: `-fshared-data'
382: Requests that the data and non-`const' variables of this
383: compilation be shared data rather than private data. The
384: distinction makes sense only on certain operating systems, where
385: shared data is shared between processes running the same program,
386: while private data exists in one copy per process.
387:
388: `-fno-common'
389: Allocate even uninitialized global variables in the bss section
390: of the object file, rather than generating them as common blocks.
391: This has the effect that if the same variable is declared
392: (without `extern') in two different compilations, you will get an
393: error when you link them. The only reason this might be useful
394: is if you wish to verify that the program will work on other
395: systems which always work this way.
396:
397: `-fno-ident'
398: Ignore the `#ident' directive.
399:
400: `-fno-gnu-linker'
401: Don't output global initializations such as C++ constructors and
402: destructors in the form used by the GNU linker (on systems where
403: the GNU linker is the standard method of handling them). Use
404: this option when you want to use a "collect" program and a
405: non-GNU linker.
406:
407: `-finhibit-size-directive'
408: Don't output a `.size' assembler directive, or anything else that
409: would cause trouble if the function is split in the middle, and
410: the two halves are placed at locations far apart in memory. This
411: option is used when compiling `crtstuff.c'; you should not need
412: to use it for anything else.
413:
414: `-fvolatile'
415: Consider all memory references through pointers to be volatile.
416:
417: `-fpic'
418: If supported for the target machines, generate
419: position-independent code, suitable for use in a shared library.
420: All addresses will be accessed through a global offset table
421: (GOT). If the GOT size for the linked executable exceeds a
422: machine-specific maximum size, you will get an error message from
423: the linker indicating that `-fpic' does not work; recompile with
424: `-fPIC' instead. (These maximums are 16k on the m88k, 8k on the
425: Sparc, and 32k on the m68k and RS/6000. The 386 has no such
426: limit.)
427:
428: Position-independent code requires special support, and therefore
429: works only on certain machines. Code generated for the IBM
430: RS/6000 is always position-independent.
431:
432: `-fPIC'
433: If supported for the target machine, emit position-independent
434: code, suitable for dynamic linking and avoiding any limit on the
435: size of the global offset table. This option makes a difference
436: on the m68k, m88k and the Sparc.
437:
438: Position-independent code requires special support, and therefore
439: works only on certain machines.
440:
441: `-ffixed-REG'
442: Treat the register named REG as a fixed register; generated code
443: should never refer to it (except perhaps as a stack pointer, frame
444: pointer or in some other fixed role).
445:
446: REG must be the name of a register. The register names accepted
447: are machine-specific and are defined in the `REGISTER_NAMES'
448: macro in the machine description macro file.
449:
450: This flag does not have a negative form, because it specifies a
451: three-way choice.
452:
453: `-fcall-used-REG'
454: Treat the register named REG as an allocatable register that is
455: clobbered by function calls. It may be allocated for temporaries
456: or variables that do not live across a call. Functions compiled
457: this way will not save and restore the register REG.
458:
459: Use of this flag for a register that has a fixed pervasive role
460: in the machine's execution model, such as the stack pointer or
461: frame pointer, will produce disastrous results.
462:
463: This flag does not have a negative form, because it specifies a
464: three-way choice.
465:
466: `-fcall-saved-REG'
467: Treat the register named REG as an allocatable register saved by
468: functions. It may be allocated even for temporaries or variables
469: that live across a call. Functions compiled this way will save
470: and restore the register REG if they use it.
471:
472: Use of this flag for a register that has a fixed pervasive role
473: in the machine's execution model, such as the stack pointer or
474: frame pointer, will produce disastrous results.
475:
476: A different sort of disaster will result from the use of this
477: flag for a register in which function values may be returned.
478:
479: This flag does not have a negative form, because it specifies a
480: three-way choice.
481:
482:
483: File: gcc.info, Node: Environment Variables, Prev: Code Gen Options, Up: Invoking GCC
484:
485: Environment Variables Affecting GNU CC
486: ======================================
487:
488: This section describes several environment variables that affect
489: how GNU CC operates. They work by specifying directories or prefixes
490: to use when searching for various kinds of files.
491:
492: Note that you can also specify places to search using options such
493: as `-B', `-I' and `-L' (*note Directory Options::.). These take
494: precedence over places specified using environment variables, which in
495: turn take precedence over those specified by the configuration of GNU
496: CC. *Note Driver::.
497:
498: `TMPDIR'
499: If `TMPDIR' is set, it specifies the directory to use for
500: temporary files. GNU CC uses temporary files to hold the output
501: of one stage of compilation which is to be used as input to the
502: next stage: for example, the output of the preprocessor, which is
503: the input to the compiler proper.
504:
505: `GCC_EXEC_PREFIX'
506: If `GCC_EXEC_PREFIX' is set, it specifies a prefix to use in the
507: names of the subprograms executed by the compiler. No slash is
508: added when this prefix is combined with the name of a subprogram,
509: but you can specify a prefix that ends with a slash if you wish.
510:
511: If GNU CC cannot find the subprogram using the specified prefix,
512: it tries looking in the usual places for the subprogram.
513:
514: Other prefixes specified with `-B' take precedence over this
515: prefix.
516:
517: This prefix is also used for finding files such as `crt0.o' that
518: are used for linking.
519:
520: In addition, the prefix is used in an unusual way in finding the
521: directories to search for header files. For each of the standard
522: directories whose name normally begins with `/usr/local/lib/gcc'
523: (more precisely, with the value of `GCC_INCLUDE_DIR'), GNU CC
524: tries replacing that beginning with the specified prefix to
525: produce an alternate directory name. Thus, with `-Bfoo/', GNU CC
526: will search `foo/bar' where it would normally search
527: `/usr/local/lib/bar'. These alternate directories are searched
528: first; the standard directories come next.
529:
530: `COMPILER_PATH'
531: The value of `COMPILER_PATH' is a colon-separated list of
532: directories, much like `PATH'. GNU CC tries the directories thus
533: specified when searching for subprograms, if it can't find the
534: subprograms using `GCC_EXEC_PREFIX'.
535:
536: `LIBRARY_PATH'
537: The value of `LIBRARY_PATH' is a colon-separated list of
538: directories, much like `PATH'. GNU CC tries the directories thus
539: specified when searching for special linker files, if it can't
540: find them using `GCC_EXEC_PREFIX'. Linking using GNU CC also
541: uses these directories when searching for ordinary libraries for
542: the `-l' option (but directories specified with `-L' come first).
543:
544: `C_INCLUDE_PATH'
545: `C++_INCLUDE_PATH'
546: `OBJC_INCLUDE_PATH'
547: These environment variables pertain to particular languages. Each
548: variable's value is a colon-separated list of directories, much
549: like `PATH'. When GNU CC searches for header files, it tries the
550: directories listed in the variable for the language you are
551: using, after the directories specified with `-I' but before the
552: standard header file directories.
553:
554: `DEPENDENCIES_OUTPUT'
555: If this variable is set, its value specifies how to output
556: dependencies for Make based on the header files processed by the
557: compiler. This output looks much like the output from the `-M'
558: option (*note Preprocessor Options::.), but it goes to a separate
559: file, and is in addition to the usual results of compilation.
560:
561: The value of `DEPENDENCIES_OUTPUT' can be just a file name, in
562: which case the Make rules are written to that file, guessing the
563: target name from the source file name. Or the value can have the
564: form `FILE TARGET', in which case the rules are written to file
565: FILE using TARGET as the target name.
566:
567:
568: File: gcc.info, Node: Installation, Next: Trouble, Prev: Invoking GCC, Up: Top
569:
570: Installing GNU CC
571: *****************
572:
573: Here is the procedure for installing GNU CC on a Unix system.
574:
575: * Menu:
576:
577: * Other Dir:: Compiling in a separate directory (not where the source is).
578: * Sun Install:: See below for installation on the Sun.
579: * 3B1 Install:: See below for installation on the 3B1.
580: * VMS Install:: See below for installation on VMS.
581: * SCO Install:: See below for installation on SCO System V 3.2.
582: (This may also be a start on solving
583: the problems of installation on Xenix.)
584: * Unos Install:: See below for installation on Unos (from CRDS).
585:
586: 1. If you have built GNU CC previously in the same directory for a
587: different target machine, do `make cleanconfig' to delete all
588: files that might be invalid.
589:
590: 2. On a Sequent system, go to the Berkeley universe.
591:
592: 3. On a System V release 4 system, make sure `/usr/bin' precedes
593: `/usr/ucb' in `PATH'. The `cc' command in `/usr/ucb' uses
594: libraries which have bugs.
595:
596: 4. Specify the host and target machine configurations. You do this
597: by running the file `configure' with appropriate arguments.
598:
599: If you are building a compiler to produce code for the machine
600: it runs on, specify just one machine type. To build a
601: cross-compiler, specify two configurations, one for the "host
602: machine" (which the compiler runs on), and one for the "target
603: machine" (which the compiler produces code for). The command
604: looks like this:
605:
606: configure --host=sun3-sunos3 --target=sparc-sun-sunos4.1
607:
608: A configuration name may be canonical or it may be more or less
609: abbreviated.
610:
611: A canonical configuration name has three parts, separated by
612: dashes. It looks like this: `CPU-COMPANY-SYSTEM'. (The three
613: parts may themselves contain dashes; `configure' can figure out
614: which dashes serve which purpose.) For example,
615: `m68k-sun-sunos4.1' specifies a Sun 3.
616:
617: You can also replace parts of the configuration by nicknames
618: or aliases. For example, `sun3' stands for `m68k-sun', so
619: `sun3-sunos4.1' is another way to specify a Sun 3. You can also
620: use simply `sun3-sunos', since the version of Sunos is assumed by
621: default to be version 4. `sun3-bsd' also works, since
622: `configure' knows that the only BSD variant on a Sun 3 is Sunos.
623:
624: You can specify a version number after any of the system
625: types, and some of the CPU types. In most cases, the version is
626: irrelevant, and will be ignored. So you might as well specify
627: the version if you know it.
628:
629: Here are the possible CPU types:
630:
631: a29k, arm, cN, hppa, i386, i860, m68000, m68k, m88k, mips,
632: ns32k, romp, rs6000, sparc, vax.
633:
634: Note that the type hppa currently works only with Berkeley
635: systems, not with HP/UX.
636:
637: Here are the recognized company names. As you can see,
638: customary abbreviations are used rather than the longer official
639: names.
640:
641: alliant, altos, apollo, att, convergent, convex, crds, dec,
642: dg, encore, harris, hp, ibm, mips, motorola, ncr, next, ns,
643: omron, sequent, sgi, sony, sun, tti, unicom.
644:
645: The company name is meaningful only to disambiguate when the
646: rest of the information supplied is insufficient. You can omit
647: it, writing just `CPU-SYSTEM', if it is not needed. For example,
648: `vax-ultrix4.2' is equivalent to `vax-dec-ultrix4.2'.
649:
650: Here is a list of system types:
651:
652: bsd, sysv, mach, minix, genix, ultrix, vms, sco, esix, isc,
653: aix, sunos, hpux, unos, luna, dgux, newsos, osfrose, osf,
654: dynix, aos, ctix.
655:
656: You can omit the system type; then `configure' guesses the
657: operating system from the CPU and company.
658:
659: Often a particular model of machine has a name. Many of these
660: names are recognized as an alias for a CPU/company combination.
661: The alias `sun3', mentioned above, is an example of this: it
662: stands for `m68k-sun'. Sometimes we accept a company name as a
663: machine name, when the name is popularly used for a particular
664: machine. Here is a table of the known machine names:
665:
666: 3300, 3b1, 7300, altos3068, altos, apollo68, att-7300,
667: balance, convex-cN, crds, decstation-3100, decstation-dec,
668: decstation, delta, encore, gmicro, hp7NN, hp8NN, hp9k2NN,
669: hp9k3NN, hp9k7NN, hp9k8NN, iris4d, iris, isi68, m3230,
670: magnum, merlin, miniframe, mmax, news-3600, news800, news,
671: next, pbd, pc532, pmax, ps2, risc-news, rtpc, sun2, sun386i,
672: sun386, sun3, sun4, symmetry, tower-32, tower.
673:
674: If you specify an impossible combination such as `i860-dg-vms',
675: then you may get an error message from `configure', or it may
676: ignore part of the information and do the best it can with the
677: rest. `configure' always prints the canonical name for the
678: alternative that it used.
679:
680: On certain systems, you must specify whether you want GNU CC
681: to work with the usual compilation tools or with the GNU
682: compilation tools (including GAS). Use the `--gas' argument when
683: you run `configure', if you want to use the GNU tools. The
684: systems were this makes a difference are `i386-ANYTHING-sysv',
685: `i860-ANYTHING-bsd', `m68k-hp-hpux', `m68k-sony-bsd',
686: `m68k-altos-sysv', `m68000-hp-hpux', and `m68000-att-sysv'. On
687: any other system, `--gas' has no effect.
688:
689: On certain systems, you must specify whether the machine has a
690: floating point unit. These systems are `m68k-sun-sunosN' and
691: `m68k-isi-bsd'. On any other system, `--nfp' currently has no
692: effect, though perhaps there are other systems where it could
693: usefully make a difference.
694:
695: If you want to install your own homemade configuration files,
696: you can use `local' as the company name to access them. If you
697: use configuration `CPU-local', the entire configuration name is
698: used to form the configuration file names.
699:
700: Thus, if you specify `m68k-local', then the files used are
701: `m68k-local.md', `m68k-local.h', `m68k-local.c',
702: `xm-m68k-local.h', `t-m68k-local', and `x-m68k-local'.
703:
704: Here is a list of configurations that have special treatment:
705:
706: `m68000-att'
707: AT&T 3b1, a.k.a. 7300 PC. Special procedures are needed to
708: compile GNU CC with this machine's standard C compiler, due
709: to bugs in that compiler. *Note 3b1 Install::. You can
710: bootstrap it more easily with previous versions of GNU CC if
711: you have them.
712:
713: `m68000-hp-bsd'
714: HP 9000 series 200 running BSD. Note that the C compiler
715: that comes with this system cannot compile GNU CC; contact
716: `[email protected]' to get binaries of GNU CC for bootstrapping.
717:
718: `m68k-altos'
719: Altos 3068. You must use the GNU assembler, linker and
720: debugger, with COFF-encapsulation. Also, you must fix a
721: kernel bug. Details in the file `ALTOS-README'.
722:
723: `m68k-hp-hpux'
724: HP 9000 series 200 or 300 running HPUX. GNU CC does not
725: support the special symbol table used by HP's debugger, but
726: you can debug programs with GDB if you specify `--gas' to
727: use the GNU tools instead. In order to use the GNU tools,
728: you must install a library conversion program called `hpxt'.
729:
730: `m68k-sun'
731: Sun 3. We do not provide a configuration file to use the
732: Sun FPA by default, because programs that establish signal
733: handlers for floating point traps inherently cannot work
734: with the FPA.
735:
736: `m88k-dgux'
737: Motorola m88k running DG/UX. To build native or cross
738: compilers on DG/UX, you must first change to the 88open BCS
739: software development environment. This is done by issuing
740: this command:
741:
742: eval `sde-target m88kbcs`
743:
744: `ns32k-encore'
745: Encore ns32000 system. Encore systems are supported only
746: under BSD.
747:
748: `ns32k-*-genix'
749: National Semiconductor ns32000 system. Genix has bugs in
750: `alloca' and `malloc'; you must get the compiled versions of
751: these from GNU Emacs.
752:
753: `ns32k-utek'
754: UTEK ns32000 system ("merlin"). The C compiler that comes
755: with this system cannot compile GNU CC; contact
756: `tektronix!reed!mason' to get binaries of GNU CC for
757: bootstrapping.
758:
759: `rs6000-ibm'
760: IBM PowerStation/6000 machines. Due to the nonstandard
761: debugging information required for this machine, `-g' is not
762: available in this configuration.
763:
764: `vax-dec-ultrix'
765: Don't try compiling with Vax C (`vcc'). It produces
766: incorrect code in some cases (for example, when `alloca' is
767: used).
768:
769: Meanwhile, compiling `cp-parse.c' with pcc does not work
770: because of an internal table size limitation in that
771: compiler. To avoid this problem, compile just the GNU C
772: compiler first, and use it to recompile building all the
773: languages that you want to run.
774:
775: Here we spell out what files will be set up by `configure'.
776: Normally you need not be concerned with these files.
777:
778: * A symbolic link named `config.h' is made to the top-level
779: config file for the machine you will run the compiler on
780: (*note Config::.). This file is responsible for defining
781: information about the host machine. It includes `tm.h'.
782:
783: The top-level config file is located in the subdirectory
784: `config'. Its name is always `xm-SOMETHING.h'; usually
785: `xm-MACHINE.h', but there are some exceptions.
786:
787: If your system does not support symbolic links, you might
788: want to set up `config.h' to contain a `#include' command
789: which refers to the appropriate file.
790:
791: * A symbolic link named `tconfig.h' is made to the top-level
792: config file for your target machine. This is used for
793: compiling certain programs to run on that machine.
794:
795: * A symbolic link named `tm.h' is made to the
796: machine-description macro file for your target machine. It
797: should be in the subdirectory `config' and its name is often
798: `MACHINE.h'.
799:
800: * A symbolic link named `md' will be made to the machine
801: description pattern file. It should be in the `config'
802: subdirectory and its name should be `MACHINE.md'; but
803: MACHINE is often not the same as the name used in the `tm.h'
804: file because the `md' files are more general.
805:
806: * A symbolic link named `aux-output.c' will be made to the
807: output subroutine file for your machine. It should be in
808: the `config' subdirectory and its name should be `MACHINE.c'.
809:
810: * The command file `configure' also constructs `Makefile' by
811: adding some text to the template file `Makefile.in'. The
812: additional text comes from files in the `config' directory,
813: named `t-TARGET' and `h-HOST'. If these files do not exist,
814: it means nothing needs to be added for a given target or
815: host.
816:
817: 5. Make sure the Bison parser generator is installed. (This is
818: unnecessary if the Bison output files `c-parse.c' and `cexp.c'
819: are more recent than `c-parse.y' and `cexp.y' and you do not plan
820: to change the `.y' files.)
821:
822: Bison versions older than Sept 8, 1988 will produce incorrect
823: output for `c-parse.c'.
824:
825: 6. Build the compiler. Just type `make LANGUAGES=c' in the compiler
826: directory.
827:
828: `LANGUAGES=c' specifies that only the C compiler should be
829: compiled. The makefile normally builds compilers for all the
830: supported languages; currently, C, C++ and Objective C. However,
831: C is the only language that is sure to work when you build with
832: other non-GNU C compilers. In addition, building anything but C
833: at this stage is a waste of time.
834:
835: In general, you can specify the languages to build by typing
836: the argument `LANGUAGES="LIST"', where LIST is one or more words
837: from the list `c', `c++', and `objective-c'.
838:
839: Ignore any warnings you may see about "statement not reached"
840: in `insn-emit.c'; they are normal. Any other compilation errors
841: may represent bugs in the port to your machine or operating
842: system, and should be investigated and reported (*note Bugs::.).
843:
844: Some commercial compilers fail to compile GNU CC because they
845: have bugs or limitations. For example, the Microsoft compiler is
846: said to run out of macro space. Some Ultrix compilers run out of
847: expression space; then you need to break up the statement where
848: the problem happens.
849:
850: 7. If you are using COFF-encapsulation, you must convert `libgcc.a'
851: to a GNU-format library at this point. See the file
852: `README-ENCAP' in the directory containing the GNU binary file
853: utilities, for directions.
854:
855: 8. Move the first-stage object files and executables into a
856: subdirectory with this command:
857:
858: make stage1
859:
860: The files are moved into a subdirectory named `stage1'. Once
861: installation is complete, you may wish to delete these files with
862: `rm -r stage1'.
863:
864: 9. Recompile the compiler with itself, with this command:
865:
866: make CC=stage1/gcc CFLAGS="-g -O -Bstage1/"
867:
868: This is called making the stage 2 compiler.
869:
870: The command shown above builds compilers for all the supported
871: languages. If you don't want them all, you can specify the
872: languages to build by typing the argument `LANGUAGES="LIST"'.
873: LIST should contain one or more words from the list `c', `c++',
874: and `objective-c', separated by spaces.
875:
876: On a 68000 or 68020 system lacking floating point hardware,
877: unless you have selected a `tm.h' file that expects by default
878: that there is no such hardware, do this instead:
879:
880: make CC=stage1/gcc CFLAGS="-g -O -Bstage1/ -msoft-float"
881:
882: 10. If you wish to test the compiler by compiling it with itself one
883: more time, do this:
884:
885: make stage2
886: make CC=stage2/gcc CFLAGS="-g -O -Bstage2/"
887:
888: This is called making the stage 3 compiler. Aside from the `-B'
889: option, the options should be the same as when you made the stage
890: 2 compiler.
891:
892: Then compare the latest object files with the stage 2 object
893: files--they ought to be identical, unless they contain time
894: stamps. On systems where object files do not contain time
895: stamps, you can do this (in Bourne shell):
896:
897: for file in *.o; do
898: cmp $file stage2/$file
899: done
900:
901: This will mention any object files that differ between stage 2
902: and stage 3. Any difference, no matter how innocuous, indicates
903: that the stage 2 compiler has compiled GNU CC incorrectly, and is
904: therefore a potentially serious bug which you should investigate
905: and report (*note Bugs::.).
906:
907: On systems that use COFF object files, bytes 5 to 8 will
908: always be different, since it is a timestamp. On these systems,
909: you can do the comparison as follows (in Bourne shell):
910:
911: for file in *.o; do
912: tail +10c $file > foo1
913: tail +10c stage2/$file > foo2
914: cmp foo1 foo2 || echo $file
915: done
916:
917: On MIPS machines, you need to use the shell script `ecoff-cmp'
918: to compare two object files if you have built the compiler with
919: the `-mno-mips-tfile' option. Thus, do this:
920:
921: for file in *.o; do
922: ecoff-cmp $file stage2/$file
923: done
924:
925: 11. Install the compiler driver, the compiler's passes and run-time
926: support. You can use the following command:
927:
928: make CC=stage2/gcc install
929:
930: (Use the same value for `CC' that you used when compiling the
931: files that are being installed.)
932:
933: This copies the files `cc1', `cpp' and `libgcc.a' to files
934: `cc1', `cpp' and `libgcc.a' in directory
935: `/usr/local/lib/gcc/TARGET/VERSION', which is where the compiler
936: driver program looks for them. Here TARGET is the target machine
937: type specified when you ran `configure', and VERSION is the
938: version number of GNU CC. This naming scheme permits various
939: versions and/or cross-compilers to coexist.
940:
941: It also copies the driver program `gcc' into the directory
942: `/usr/local/bin', so that it appears in typical execution search
943: paths.
944:
945: *Warning: there is a bug in `alloca' in the Sun library. To
946: avoid this bug, install the binaries of GNU CC that were compiled
947: by GNU CC. They use `alloca' as a built-in function and never
948: the one in the library.*
949:
950: 12. If you will be using C++ or Objective C, and your operating
951: system does not handle constructors, then you must build and
952: install the program `collect2'. Do this with the following
953: command:
954:
955: make CC="stage2/gcc -O" install-collect2
956:
957: The systems that *do* handle constructors on their own include
958: system V release 4, and system V release 3 on the Intel 386.
959:
960: Berkeley systems that use the "a.out" object file format handle
961: constructors without `collect2' if you use the GNU linker. But if
962: you don't use the GNU linker, then you need `collect2' on these
963: systems.
964:
965: 13. Build and install `protoize' if you want it. Type
966:
967: make CC="stage2/gcc -O" install-proto
968:
969: There is as yet no documentation for `protoize'. Sorry.
970:
971: 14. Correct errors in the header files on your machine.
972:
973: Various system header files often contain constructs which are
974: incompatible with ANSI C, and they will not work when you compile
975: programs with GNU CC. This behavior consists of substituting for
976: macro argument names when they appear inside of character
977: constants. The most common offender is `ioctl.h'.
978:
979: You can overcome this problem when you compile by specifying
980: the `-traditional' option.
981:
982: Alternatively, on Sun systems and 4.3BSD at least, you can
983: correct the include files by running the shell script
984: `fixincludes'. This installs modified, corrected copies of the
985: files `ioctl.h', `ttychars.h' and many others, in a special
986: directory where only GNU CC will normally look for them. This
987: script will work on various systems because it chooses the files
988: by searching all the system headers for the problem cases that we
989: know about.
990:
991: Use the following command to do this:
992:
993: make install-fixincludes
994:
995: If you selected a different directory for GNU CC installation
996: when you installed it, by specifying the Make variable `prefix' or
997: `libdir', specify it the same way in this command.
998:
999: Note that some systems are starting to come with ANSI C system
1000: header files. On these systems, don't run `fixincludes'; it may
1001: not work, and is certainly not necessary.
1002:
1003: If you cannot install the compiler's passes and run-time support in
1004: `/usr/local/lib', you can alternatively use the `-B' option to specify
1005: a prefix by which they may be found. The compiler concatenates the
1006: prefix with the names `cpp', `cc1' and `libgcc.a'. Thus, you can put
1007: the files in a directory `/usr/foo/gcc' and specify `-B/usr/foo/gcc/'
1008: when you run GNU CC.
1009:
1010: Also, you can specify an alternative default directory for these
1011: files by setting the Make variable `libdir' when you make GNU CC.
1012:
1013:
1014: File: gcc.info, Node: Other Dir, Next: Sun Install, Prev: Installation, Up: Installation
1015:
1016: Compilation in a Separate Directory
1017: ===================================
1018:
1019: If you wish to build the object files and executables in a directory
1020: other than the one containing the source files, here is what you must
1021: do differently:
1022:
1023: 1. Make sure you have a version of Make that supports the `VPATH'
1024: feature. (GNU Make supports it, as do Make versions on most BSD
1025: systems.)
1026:
1027: 2. Go to that directory before running `configure':
1028:
1029: mkdir gcc-sun3
1030: cd gcc-sun3
1031:
1032: On systems that do not support symbolic links, this directory
1033: must be on the same file system as the source code directory.
1034:
1035: 3. Specify where to find `configure' when you run it:
1036:
1037: ../gcc-2.00/configure ...
1038:
1039: This also tells `configure' where to find the compiler sources;
1040: `configure' takes the directory from the file name that was used
1041: to invoke it. But if you want to be sure, you can specify the
1042: source directory with the `--srcdir' option, like this:
1043:
1044: ../gcc-2.00/configure --srcdir=../gcc-2.00 sun3
1045:
1046: The directory you specify with `--srcdir' need not be the same
1047: as the one that `configure' is found in.
1048:
1049: Now, you can run `make' in that directory. You need not repeat the
1050: configuration steps shown above, when ordinary source files change.
1051: You must, however, run `configure' again when the configuration files
1052: change, if your system does not support symbolic links.
1053:
1054:
1055: File: gcc.info, Node: Sun Install, Next: 3b1 Install, Prev: Other Dir, Up: Installation
1056:
1057: Installing GNU CC on the Sun
1058: ============================
1059:
1060: Make sure the environment variable `FLOAT_OPTION' is not set when
1061: you compile `libgcc.a'. If this option were set to `f68881' when
1062: `libgcc.a' is compiled, the resulting code would demand to be linked
1063: with a special startup file and would not link properly without
1064: special pains.
1065:
1066: There is a bug in `alloca' in certain versions of the Sun library.
1067: To avoid this bug, install the binaries of GNU CC that were compiled by
1068: GNU CC. They use `alloca' as a built-in function and never the one in
1069: the library.
1070:
1071: Some versions of the Sun compiler crash when compiling GNU CC. The
1072: problem is a segmentation fault in cpp. This problem seems to be due
1073: to the bulk of data in the environment variables. You may be able to
1074: avoid it by using the following command to compile GNU CC with Sun CC:
1075:
1076: make CC="TERMCAP=x OBJS=x LIBFUNCS=x STAGESTUFF=x cc"
1077:
1078:
1079: File: gcc.info, Node: 3b1 Install, Next: SCO Install, Prev: Sun Install, Up: Installation
1080:
1081: Installing GNU CC on the 3b1
1082: ============================
1083:
1084: Installing GNU CC on the 3b1 is difficult if you do not already have
1085: GNU CC running, due to bugs in the installed C compiler. However, the
1086: following procedure might work. We are unable to test it.
1087:
1088: 1. Comment out the `#include "config.h"' line on line 37 of `cccp.c'
1089: and do `make cpp'. This makes a preliminary version of GNU cpp.
1090:
1091: 2. Save the old `/lib/cpp' and copy the preliminary GNU cpp to that
1092: file name.
1093:
1094: 3. Undo your change in `cccp.c', or reinstall the original version,
1095: and do `make cpp' again.
1096:
1097: 4. Copy this final version of GNU cpp into `/lib/cpp'.
1098:
1099: 5. Replace every occurrence of `obstack_free' in the file `tree.c'
1100: with `_obstack_free'.
1101:
1102: 6. Run `make' to get the first-stage GNU CC.
1103:
1104: 7. Reinstall the original version of `/lib/cpp'.
1105:
1106: 8. Now you can compile GNU CC with itself and install it in the
1107: normal fashion.
1108:
1109:
1110: File: gcc.info, Node: SCO Install, Next: Unos Install, Prev: 3B1 Install, Up: Installation
1111:
1112: Installing GNU CC on SCO System V 3.2
1113: =====================================
1114:
1115: The compiler that comes with this system does not work properly with
1116: `-O'. Therefore, you should redefine the Make variable `CCLIBFLAGS'
1117: not to use `-O'.
1118:
1119: In addition, the compiler produces incorrect output when compiling
1120: parts of GNU CC; the resulting executable `cc1' does not work properly
1121: when it is used with `-O'.
1122:
1123: Therefore, what you must do after building the first stage is use
1124: GNU CC to compile itself without optimization. Here is how:
1125:
1126: make -k cc1 CC="./gcc -B./"
1127:
1128: You can think of this as "stage 1.1" of the installation process.
1129: However, using this command has the effect of discarding the faulty
1130: stage 1 executable for `cc1' and replacing it with stage 1.1. You can
1131: then proceed with `make stage1' and the rest of installation.
1132:
1133: On Xenix, the same thing is necessary; in addition, you may have to
1134: remove `-g' from the options used with `cc', and you may have to
1135: simplify complicated statements in the sources of GNU CC to get them
1136: to compile.
1137:
1138:
1139: File: gcc.info, Node: Unos Install, Next: VMS Install, Prev: SCO Install, Up: Installation
1140:
1141: Installing GNU CC on Unos
1142: =========================
1143:
1144: Use `configure unos' for building on Unos.
1145:
1146: The Unos assembler is named `casm' instead of `as'. For some
1147: strange reason linking `/bin/as' to `/bin/casm' changes the behavior,
1148: and does not work. So, when installing GNU CC, you should install the
1149: following script as `as' in the subdirectory where the passes of GCC
1150: are installed:
1151:
1152: #!/bin/sh
1153: casm $*
1154:
1155: The default Unos library is named `libunos.a' instead of `libc.a'.
1156: To allow GNU CC to function, either change all references to `-lc' in
1157: `gcc.c' to `-lunos' or link `/lib/libc.a' to `/lib/libunos.a'.
1158:
1159: When compiling GNU CC with the standard compiler, to overcome bugs
1160: in the support of `alloca', do not use `-O' when making stage 2. Then
1161: use the stage 2 compiler with `-O' to make the stage 3 compiler. This
1162: compiler will have the same characteristics as the usual stage 2
1163: compiler on other systems. Use it to make a stage 4 compiler and
1164: compare that with stage 3 to verify proper compilation.
1165:
1166: Unos uses memory segmentation instead of demand paging, so you will
1167: need a lot of memory. 5 Mb is barely enough if no other tasks are
1168: running. If linking `cc1' fails, try putting the object files into a
1169: library and linking from that library.
1170:
1171:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.