![[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 [Apple XNU] / GNUtools / cc|
Return to INSTALL CVS log | Up to [Apple XNU] / GNUtools / cc |
1.1 root 1: This file documents the installation of the GNU compiler. Copyright
2: (C) 1988, 1989, 1992 Free Software Foundation, Inc. You may copy,
3: distribute, and modify it freely as long as you preserve this copyright
4: notice and permission notice.
5:
6: Installing GNU CC
7: *****************
8:
9: Here is the procedure for installing GNU CC on a Unix system.
10:
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:
16: 1. If you have built GNU CC previously in the same directory for a
17: different target machine, do `make distclean' to delete all files
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.
22:
23: 2. On a System V release 4 system, make sure `/usr/bin' precedes
24: `/usr/ucb' in `PATH'. The `cc' command in `/usr/ucb' uses
25: libraries which have bugs.
26:
27: 3. Specify the host and target machine configurations. You do this by
28: running the file `configure' with appropriate arguments.
29:
30: If you are building a compiler to produce code for the machine it
31: runs on, specify just one machine type, with the `--target'
32: option; the host type will default to be the same as the target.
33: (For information on building a cross-compiler, see *Note
34: Cross-Compiler::.) Here is an example:
35:
36: configure --target=sparc-sun-sunos4.1
37:
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:
44: A configuration name may be canonical or it may be more or less
45: abbreviated.
46:
47: A canonical configuration name has three parts, separated by
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.
52:
53: You can also replace parts of the configuration by nicknames or
54: aliases. For example, `sun3' stands for `m68k-sun', so
55: `sun3-sunos4.1' is another way to specify a Sun 3. You can also
56: use simply `sun3-sunos', since the version of SunOS is assumed by
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.
64:
65: Here are the possible CPU types:
66:
67: a29k, alpha, arm, cN, clipper, elxsi, h8300, hppa1.0, hppa1.1,
68: i370, i386, i486, i860, i960, m68000, m68k, m88k, mips,
69: ns32k, pyramid, romp, rs6000, sh, sparc, sparclite, vax,
70: we32k.
71:
72: Here are the recognized company names. As you can see, customary
73: abbreviations are used rather than the longer official names.
74:
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.
79:
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,
83: `vax-ultrix4.2' is equivalent to `vax-dec-ultrix4.2'.
84:
85: Here is a list of system types:
86:
87: aix, acis, aos, bsd, clix, ctix, dgux, dynix, genix, hpux,
88: isc, linux, luna, lynxos, mach, minix, newsos, osf, osfrose,
89: riscos, sco, solaris, sunos, sysv, ultrix, unos, vms.
90:
91: You can omit the system type; then `configure' guesses the
92: operating system from the CPU and company.
93:
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
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:
100: If you specify an impossible combination such as `i860-dg-vms',
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
103: rest. `configure' always prints the canonical name for the
104: alternative that it used.
105:
106: Often a particular model of machine has a name. Many machine
107: names are recognized as aliases for CPU/company combinations.
108: Thus, the machine name `sun3', mentioned above, is an alias for
109: `m68k-sun'. Sometimes we accept a company name as a machine name,
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.
120:
121: Remember that a machine name specifies both the cpu type and the
122: company name.
123:
124: There are four additional options you can specify independently to
125: describe variant hardware and software configurations. These are
126: `--with-gnu-as', `--with-gnu-ld', `--with-stabs' and `--nfp'.
127:
128: `--with-gnu-as'
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:
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.
144:
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').
158:
159: `--with-gnu-ld'
160: Specify the option `--with-gnu-ld' if you plan to use the GNU
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.
168:
169: `--with-stabs'
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.
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:
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:
192: `--nfp'
193: On certain systems, you must specify whether the machine has
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.
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
201: configuration `CPU-local', the configuration name without the cpu
202: prefix is used to form the configuration file names.
203:
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'.
207:
208: Here is a list of configurations that have special treatment or
209: special things you must know:
210:
211: `alpha-*-osf1'
212: Systems using processors that implement the DEC Alpha
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:
217: Objective C and C++ do not yet work on the Alpha. We hope to
218: support C++ in version 2.6.
219:
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.
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
232: value on the host cannot be performed. Building
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.
263:
264: `a29k'
265: AMD Am29k-family processors. These are normally used in
266: embedded applications. There are no standard Unix
267: configurations. This configuration corresponds to AMD's
268: standard calling sequence and binary interface and is
269: compatible with other 29k tools.
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:
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:
287: `i386-*-sco'
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:
292: `i386-*-sco3.2.4'
293: Use this configuration for SCO release 3.2 version 4.
294:
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.
302:
303: `i386-ibm-aix'
304: You need to use GAS version 2.1 or later, and and LD from GNU
305: binutils version 2.2 or later.
306:
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:
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:
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:
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
336: `[email protected]' to get binaries of GNU CC for bootstrapping.
337:
338: `m68k-altos'
339: Altos 3068. You must use the GNU assembler, linker and
340: debugger. Also, you must fix a kernel bug. Details in the
341: file `README.ALTOS'.
342:
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:
353: `m68k-hp-hpux'
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.
361:
362: `m68k-sun'
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:
368: `m88k-*-svr3'
369: Motorola m88k running the AT&T/Unisoft/Motorola V.3 reference
370: port. These systems tend to use the Green Hills C, revision
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
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.
381:
382: `m88k-*-dgux'
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:
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:
399: `mips-mips-bsd'
400: MIPS machines running the MIPS operating system in BSD mode.
401: It's possible that some old versions of the system lack the
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:
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:
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
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.
418:
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:
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:
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:
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.
443: We recommend you compile GNU CC with an earlier version of
444: itself; if you compile GNU CC with `hc', the Metaware
445: compiler, it will work, but you will get mismatches between
446: the stage 2 and stage 3 compilers in various files. These
447: errors are minor differences in some floating-point constants
448: and can be safely ignored; the stage 3 compiler is correct.
449:
450: `rs6000-*-aix'
451: *Read the file `README.RS6000' for information on how to get
452: a fix for problems in the IBM assembler that interfere with
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'.
456:
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:
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:
478: Here we spell out what files will be set up by `configure'.
479: Normally you need not be concerned with these files.
480:
481: * A symbolic link named `config.h' is made to the top-level
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'.
486:
487: The top-level config file is located in the subdirectory
488: `config'. Its name is always `xm-SOMETHING.h'; usually
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'
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.
509:
510: * A symbolic link named `aux-output.c' will be made to the
511: output subroutine file for your machine. It should be in the
512: `config' subdirectory and its name should be `MACHINE.c'.
513:
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.)
532:
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:
536: 6. Make sure the Bison parser generator is installed. (This is
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.)
540:
541: Bison versions older than Sept 8, 1988 will produce incorrect
542: output for `c-parse.c'.
543:
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
556: directory.
557:
558: `LANGUAGES=c' specifies that only the C compiler should be
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:
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
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.
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
579: expression space; then you need to break up the statement where
580: the problem happens.
581:
582: If you are building with a previous GNU C compiler, do not use
583: `CC=gcc' on the make command or by editing the Makefile. Instead,
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:
589: 9. If you are building a cross-compiler, stop here. *Note
590: Cross-Compiler::.
591:
592: 10. Move the first-stage object files and executables into a
593: subdirectory with this command:
594:
595: make stage1
596:
597: The files are moved into a subdirectory named `stage1'. Once
598: installation is complete, you may wish to delete these files with
599: `rm -r stage1'.
600:
601: 11. If you have chosen a configuration for GNU CC which requires other
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:
612: 12. Recompile the compiler with itself, with this command:
613:
614: make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O"
615:
616: This is called making the stage 2 compiler.
617:
618: The command shown above builds compilers for all the supported
619: languages. If you don't want them all, you can specify the
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:
636:
637: make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O -msoft-float"
638:
639: 13. If you wish to test the compiler by compiling it with itself one
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:
643:
644: make stage2
645: make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O"
646:
647: This is called making the stage 3 compiler. Aside from the `-B'
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.
654:
655: Then compare the latest object files with the stage 2 object
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:
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
670: therefore a potentially serious bug which you should investigate
671: and report.
672:
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):
675:
676: for file in *.o; do
677: cmp $file stage2/$file
678: done
679:
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.
682:
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"
694:
695: 15. Install the compiler driver, the compiler's passes and run-time
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.
702:
703: For example, if you have built the stage 2 compiler, you can use
704: the following command:
705:
706: make install CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" LANGUAGES="LIST"
707:
708: This copies the files `cc1', `cpp' and `libgcc.a' to files `cc1',
709: `cpp' and `libgcc.a' in the directory
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
714: versions and/or cross-compilers to coexist.
715:
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.
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.*
729:
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
732: some other compiler.)
733:
734: 16. Install the Objective C library (if you are installing the
735: Objective C compiler). Here is the command to do this:
736:
737: make install-libobjc CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O"
738:
739: 17. If you're going to use C++, it's likely that you need to also
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
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
744: libraries, etc., are available in the libg++ distribution.
745:
746: Compilation in a Separate Directory
747: ===================================
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:
757: 2. If you have ever run `configure' in the source directory, you must
758: undo the configuration. Do this by running:
759:
760: make distclean
761:
762: 3. Go to the directory in which you want to build the compiler before
763: running `configure':
764:
765: mkdir gcc-sun3
766: cd gcc-sun3
767:
768: On systems that do not support symbolic links, this directory must
769: be on the same file system as the source code directory.
770:
771: 4. Specify where to find `configure' when you run it:
772:
773: ../gcc/configure ...
774:
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:
779:
780: ../gcc/configure --srcdir=../gcc sun3
781:
782: The directory you specify with `--srcdir' need not be the same as
783: the one that `configure' is found in.
784:
785: Now, you can run `make' in that directory. You need not repeat the
786: configuration steps shown above, when ordinary source files change. You
787: must, however, run `configure' again when the configuration files
788: change, if your system does not support symbolic links.
789:
790: Building and Installing a Cross-Compiler
791: ========================================
792:
793: GNU CC can function as a cross-compiler for many machines, but not
794: all.
795:
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.
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:
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:
844: To build GNU CC as a cross-compiler, you start out by running
845: `configure'. You must specify two different configurations, the host
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:
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
1012: compiler.
1013:
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:
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:
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).
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:
1079: To install the cross-compiler, use `make install', as usual.
1080:
1081: Installing on the HP Precision Architecture
1082: ===========================================
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
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
1100:
1101: /usr/local/lib/gcc-lib/CONFIGURATION/GCCVERSION/as
1102:
1103: where CONFIGURATION is the configuration name (perhaps `hpNNN-hpux')
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
1107:
1108: make install-dir
1109:
1110: will create the necessary directory hierarchy so you can install GAS
1111: before building GCC.
1112:
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.
1119:
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
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".
1133:
1134: Installing GNU CC on the Sun
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'.
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
1143: with a special startup file and would not link properly without special
1144: pains.
1145:
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:
1156: There is a bug in `alloca' in certain versions of the Sun library.
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
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:
1165:
1166: make CC="TERMCAP=x OBJS=x LIBFUNCS=x STAGESTUFF=x cc"
1167:
1168: Installing GNU CC on the 3b1
1169: ============================
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:
1193: 8. Now you can compile GNU CC with itself and install it in the normal
1194: fashion.
1195:
1196: Installing GNU CC on Unos
1197: =========================
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:
1210: The default Unos library is named `libunos.a' instead of `libc.a'.
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:
1214: When compiling GNU CC with the standard compiler, to overcome bugs in
1215: the support of `alloca', do not use `-O' when making stage 2. Then use
1216: the stage 2 compiler with `-O' to make the stage 3 compiler. This
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:
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:
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
1227: running. If linking `cc1' fails, try putting the object files into a
1228: library and linking from that library.
1229:
1230: Installing GNU CC on VMS
1231: ========================
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
1237: the same manner as you use the VMS C compiler, you must install the VMS
1238: CLD file for GNU CC as follows:
1239:
1240: 1. Define the VMS logical names `GNU_CC' and `GNU_CC_INCLUDE' to
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:
1244:
1245: $ assign /system /translation=concealed -
1246: disk:[gcc.] gnu_cc
1247: $ assign /system /translation=concealed -
1248: disk:[gcc.include.] gnu_cc_include
1249:
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.
1254:
1255: 2. Install the `GCC' command with the command line:
1256:
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
1260:
1261: 3. To install the help file, do the following:
1262:
1263: $ library/help sys$library:helplib.hlb gcc.hlp
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
1274: files. This can be done with the command:
1275:
1276: $ assign /system /translation=concealed -
1277: disk:[gcc.gxx_include.] gnu_gxx_include
1278:
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.
1282:
1283: 2. Obtain the file `gcc-cc1plus.exe', and place this in the same
1284: directory that `gcc-cc1.exe' is kept.
1285:
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.
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
1292: version than the sources, because we don't always have time to update
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
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:
1297:
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'.
1303:
1304: $ @vmsconfig.com
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:
1311: $ assign /system /translation=concealed -
1312: disk:[bison.] gnu_bison
1313:
1314: You may, if you choose, use the `INSTALL_BISON.COM' script in the
1315: `[BISON]' directory.
1316:
1317: 3. Install the `BISON' command with the command line:
1318:
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
1323:
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
1327: first edit `make-gcc.com' and follow the instructions that appear
1328: in the comments.
1329:
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
1334: generate the library `libgcc2.olb'. `libgcc2.olb' should be built
1335: using the compiler built from the same distribution that
1336: `libgcc2.c' came from, and `make-gcc.com' will automatically do
1337: all of this for you.
1338:
1339: To install the library, use the following commands:
1340:
1341: $ library gnu_cc:[000000]gcclib/delete=(new,eprintf)
1342: $ library gnu_cc:[000000]gcclib/delete=L_*
1343: $ library libgcc2/extract=*/output=libgcc2.obj
1344: $ library gnu_cc:[000000]gcclib libgcc2.obj
1345:
1346: The first command simply removes old modules that will be replaced
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'.
1353:
1354: Whenever you update the compiler on your system, you should also
1355: update the library with the above procedure.
1356:
1357: 6. You may wish to build GCC in such a way that no files are written
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:
1363: $ assign dua0:[gcc.build_dir.]/translation=concealed, -
1364: dua1:[gcc.source_dir.]/translation=concealed gcc_build
1365: $ set default gcc_build:[000000]
1366:
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).
1374:
1375: 7. *If you are building GNU CC with a previous version of GNU CC, you
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
1380: version 2. If you use GAS 1.38.1, then `extern const' variables
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.
1385:
1386: If you are compiling with a version of GNU CC older than 1.33,
1387: specify `/DEFINE=("inline=")' as an option in all the
1388: compilations. This requires editing all the `gcc' commands in
1389: `make-cc1.com'. (The older versions had problems supporting
1390: `inline'.) Once you have a working 1.33 or newer GNU CC, you can
1391: change this file back.
1392:
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:
1416: Under previous versions of GNU CC, the generated code would
1417: occasionally give strange results when linked with the sharable
1418: `VAXCRTL' library. Now this should work.
1419:
1420: Even with this version, however, GNU CC itself should not be linked
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.
1424:
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'.
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
1436: ==============================
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
1453: echo '/lib/cpp.gnu -traditional ${1+"$@"}' > /lib/cpp
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
1458: optimization. Then build a stage 3 compiler with optimization. That
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
1469: =============================
1470:
1471: See *Note Installation:: about whether to use either of the options
1472: `--with-stabs' or `--with-gnu-as'.
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
1477: to use `-Olimit 3000'. Both of these options are automatically
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.
1517:
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:
1572: Cross-compilers search a little differently:
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:
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.