![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to INSTALL CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to INSTALL CVS log | Up to [GCC 2.x] / gcc |
1.1 root 1: This is a copy of one chapter from the Info file gcc.info*.
2: For full information on installing and porting GCC, refer to the
3: GCC manual:
4:
5: Info file gcc.info
6: TeX output gcc.dvi
7: TeX source gcc.texinfo
8:
9:
10: Installing GNU CC
11: *****************
12:
13: Here is the procedure for installing GNU CC on a Unix system.
14:
1.1.1.2 ! root 15: * Menu:
! 16:
! 17: * Other Dir:: Compiling in a separate directory (not where the source is).
! 18: * Sun Install:: See below for installation on the Sun.
! 19: * 3B1 Install:: See below for installation on the 3B1.
! 20: * VMS Install:: See below for installation on VMS.
! 21: * Unos Install:: See below for installation on Unos (from CRDS).
! 22:
1.1 root 23: 1. If you have built GNU CC previously in the same directory for a
1.1.1.2 ! root 24: different target machine, do `make distclean' to delete all files
! 25: that might be invalid.
1.1 root 26:
27: 2. On a Sequent system, go to the Berkeley universe.
28:
29: 3. On a System V release 4 system, make sure `/usr/bin' precedes
30: `/usr/ucb' in `PATH'. The `cc' command in `/usr/ucb' uses
31: libraries which have bugs.
32:
33: 4. Specify the host and target machine configurations. You do this
34: by running the file `configure' with appropriate arguments.
35:
36: If you are building a compiler to produce code for the machine
37: it runs on, specify just one machine type. To build a
38: cross-compiler, specify two configurations, one for the "host
39: machine" (which the compiler runs on), and one for the "target
40: machine" (which the compiler produces code for). The command
41: looks like this:
42:
43: configure --host=sun3-sunos3 --target=sparc-sun-sunos4.1
44:
45: A configuration name may be canonical or it may be more or less
46: abbreviated.
47:
48: A canonical configuration name has three parts, separated by
49: dashes. It looks like this: `CPU-COMPANY-SYSTEM'. (The three
50: parts may themselves contain dashes; `configure' can figure out
51: which dashes serve which purpose.) For example,
52: `m68k-sun-sunos4.1' specifies a Sun 3.
53:
54: You can also replace parts of the configuration by nicknames
55: or aliases. For example, `sun3' stands for `m68k-sun', so
56: `sun3-sunos4.1' is another way to specify a Sun 3. You can also
1.1.1.2 ! root 57: use simply `sun3-sunos', since the version of SunOS is assumed by
1.1 root 58: default to be version 4. `sun3-bsd' also works, since
1.1.1.2 ! root 59: `configure' knows that the only BSD variant on a Sun 3 is SunOS.
1.1 root 60:
61: You can specify a version number after any of the system
62: types, and some of the CPU types. In most cases, the version is
63: irrelevant, and will be ignored. So you might as well specify
64: the version if you know it.
65:
66: Here are the possible CPU types:
67:
68: a29k, arm, cN, hppa, i386, i860, m68000, m68k, m88k, mips,
69: ns32k, romp, rs6000, sparc, vax.
70:
71: Here are the recognized company names. As you can see,
72: customary abbreviations are used rather than the longer official
73: names.
74:
75: alliant, altos, apollo, att, convergent, convex, crds, dec,
76: dg, encore, harris, hp, ibm, mips, motorola, ncr, next, ns,
77: omron, sequent, sgi, sony, sun, tti, unicom.
78:
79: The company name is meaningful only to disambiguate when the
80: rest of the information supplied is insufficient. You can omit
81: it, writing just `CPU-SYSTEM', if it is not needed. For example,
82: `vax-ultrix4.2' is equivalent to `vax-dec-ultrix4.2'.
83:
84: Here is a list of system types:
85:
1.1.1.2 ! root 86: bsd, sysv, mach, minix, genix, ultrix, vms, sco, isc, aix,
! 87: sunos, hpux, unos, luna, dgux, newsos, osfrose, osf, dynix,
! 88: aos, ctix.
1.1 root 89:
90: You can omit the system type; then `configure' guesses the
91: operating system from the CPU and company.
92:
1.1.1.2 ! root 93: You can add a version number to the system type; this may or
! 94: may not make a difference. For example, you can write `bsd4.3' or
! 95: `bsd4.4' to distinguish versions of BSD. In practice, the version
! 96: number is most needed for `sysv3' and `sysv4', which are often
! 97: treated differently.
! 98:
! 99: If you specify an impossible combination such as `i860-dg-vms',
! 100: then you may get an error message from `configure', or it may
! 101: ignore part of the information and do the best it can with the
! 102: rest. `configure' always prints the canonical name for the
! 103: alternative that it used.
! 104:
! 105: Often a particular model of machine has a name. Many machine
! 106: names are recognized as aliases for CPU/company combinations.
! 107: Thus, the machine name `sun3', mentioned above, is an alias for
! 108: `m68k-sun'. Sometimes we accept a company name as a machine
! 109: name, when the name is popularly used for a particular machine.
! 110: Here is a table of the known machine names:
1.1 root 111:
112: 3300, 3b1, 7300, altos3068, altos, apollo68, att-7300,
113: balance, convex-cN, crds, decstation-3100, decstation-dec,
114: decstation, delta, encore, gmicro, hp7NN, hp8NN, hp9k2NN,
115: hp9k3NN, hp9k7NN, hp9k8NN, iris4d, iris, isi68, m3230,
116: magnum, merlin, miniframe, mmax, news-3600, news800, news,
117: next, pbd, pc532, pmax, ps2, risc-news, rtpc, sun2, sun386i,
118: sun386, sun3, sun4, symmetry, tower-32, tower.
119:
1.1.1.2 ! root 120: Remember that a machine name specifies both the cpu type and the
! 121: company name.
1.1 root 122:
123: On certain systems, you must specify whether you want GNU CC
124: to work with the usual compilation tools or with the GNU
125: compilation tools (including GAS). Use the `--gas' argument when
126: you run `configure', if you want to use the GNU tools. The
127: systems were this makes a difference are `i386-ANYTHING-sysv',
128: `i860-ANYTHING-bsd', `m68k-hp-hpux', `m68k-sony-bsd',
129: `m68k-altos-sysv', `m68000-hp-hpux', and `m68000-att-sysv'. On
130: any other system, `--gas' has no effect.
131:
132: On certain systems, you must specify whether the machine has a
133: floating point unit. These systems are `m68k-sun-sunosN' and
134: `m68k-isi-bsd'. On any other system, `--nfp' currently has no
135: effect, though perhaps there are other systems where it could
136: usefully make a difference.
137:
138: If you want to install your own homemade configuration files,
139: you can use `local' as the company name to access them. If you
140: use configuration `CPU-local', the entire configuration name is
141: used to form the configuration file names.
142:
143: Thus, if you specify `m68k-local', then the files used are
144: `m68k-local.md', `m68k-local.h', `m68k-local.c',
145: `xm-m68k-local.h', `t-m68k-local', and `x-m68k-local'.
146:
1.1.1.2 ! root 147: Here is a list of configurations that have special treatment
! 148: or special things you must know:
! 149:
! 150: `hppa-hp-hpux'
! 151: HP precision architecture, running HP-UX. `-g' does not work
! 152: on this configuration, since the system uses a peculiar
! 153: debugging format which GNU CC does not know about.
! 154:
! 155: `i386-*-sco'
! 156: Compilation with RCC is recommended, but it produces lots of
! 157: spurious warnings. They do not necessarily indicate that
! 158: anything is wrong.
1.1 root 159:
160: `m68000-att'
161: AT&T 3b1, a.k.a. 7300 PC. Special procedures are needed to
162: compile GNU CC with this machine's standard C compiler, due
163: to bugs in that compiler. *Note 3b1 Install::. You can
164: bootstrap it more easily with previous versions of GNU CC if
165: you have them.
166:
167: `m68000-hp-bsd'
168: HP 9000 series 200 running BSD. Note that the C compiler
169: that comes with this system cannot compile GNU CC; contact
170: `[email protected]' to get binaries of GNU CC for bootstrapping.
171:
172: `m68k-altos'
173: Altos 3068. You must use the GNU assembler, linker and
174: debugger, with COFF-encapsulation. Also, you must fix a
175: kernel bug. Details in the file `ALTOS-README'.
176:
177: `m68k-hp-hpux'
1.1.1.2 ! root 178: HP 9000 series 300 or 400 running HP-UX. HP-UX version 8.0
! 179: has a bug in the assembler that prevents compilation of GNU
! 180: CC. To fix it, get patch PHCO_0800 from HP.
! 181:
! 182: In addition, `--gas' does not currently work with this
! 183: configuration. Changes in HP-UX have broken the library
! 184: conversion tool and the linker.
1.1 root 185:
186: `m68k-sun'
187: Sun 3. We do not provide a configuration file to use the
188: Sun FPA by default, because programs that establish signal
189: handlers for floating point traps inherently cannot work
190: with the FPA.
191:
192: `m88k-dgux'
193: Motorola m88k running DG/UX. To build native or cross
194: compilers on DG/UX, you must first change to the 88open BCS
195: software development environment. This is done by issuing
196: this command:
197:
198: eval `sde-target m88kbcs`
199:
1.1.1.2 ! root 200: `mips-mips-bsd'
! 201: MIPS machines running the MIPS operating system in BSD mode.
! 202: It's possible that some old versions of the system lack the
! 203: functions `memcpy', `memcmp', and `memset'. If your system
! 204: lacks these, you must remove or undo the definition of
! 205: `TARGET_MEM_FUNCTIONS' in `mips-bsd.h'.
! 206:
1.1 root 207: `ns32k-encore'
208: Encore ns32000 system. Encore systems are supported only
209: under BSD.
210:
211: `ns32k-*-genix'
212: National Semiconductor ns32000 system. Genix has bugs in
213: `alloca' and `malloc'; you must get the compiled versions of
214: these from GNU Emacs.
215:
216: `ns32k-utek'
217: UTEK ns32000 system ("merlin"). The C compiler that comes
218: with this system cannot compile GNU CC; contact
219: `tektronix!reed!mason' to get binaries of GNU CC for
220: bootstrapping.
221:
1.1.1.2 ! root 222: `pyramid'
! 223: The Pyramid C compler is reported to be unable to compile
! 224: GNU CC. You must use an older version of GNU CC for
! 225: bootstrapping.
1.1 root 226:
227: `vax-dec-ultrix'
228: Don't try compiling with Vax C (`vcc'). It produces
229: incorrect code in some cases (for example, when `alloca' is
230: used).
231:
232: Meanwhile, compiling `cp-parse.c' with pcc does not work
233: because of an internal table size limitation in that
234: compiler. To avoid this problem, compile just the GNU C
235: compiler first, and use it to recompile building all the
236: languages that you want to run.
237:
238: Here we spell out what files will be set up by `configure'.
239: Normally you need not be concerned with these files.
240:
241: * A symbolic link named `config.h' is made to the top-level
242: config file for the machine you will run the compiler on
243: (*note Config::.). This file is responsible for defining
244: information about the host machine. It includes `tm.h'.
245:
246: The top-level config file is located in the subdirectory
247: `config'. Its name is always `xm-SOMETHING.h'; usually
248: `xm-MACHINE.h', but there are some exceptions.
249:
250: If your system does not support symbolic links, you might
251: want to set up `config.h' to contain a `#include' command
252: which refers to the appropriate file.
253:
254: * A symbolic link named `tconfig.h' is made to the top-level
255: config file for your target machine. This is used for
256: compiling certain programs to run on that machine.
257:
258: * A symbolic link named `tm.h' is made to the
259: machine-description macro file for your target machine. It
260: should be in the subdirectory `config' and its name is often
261: `MACHINE.h'.
262:
263: * A symbolic link named `md' will be made to the machine
264: description pattern file. It should be in the `config'
265: subdirectory and its name should be `MACHINE.md'; but
266: MACHINE is often not the same as the name used in the `tm.h'
267: file because the `md' files are more general.
268:
269: * A symbolic link named `aux-output.c' will be made to the
270: output subroutine file for your machine. It should be in
271: the `config' subdirectory and its name should be `MACHINE.c'.
272:
273: * The command file `configure' also constructs `Makefile' by
274: adding some text to the template file `Makefile.in'. The
275: additional text comes from files in the `config' directory,
276: named `t-TARGET' and `h-HOST'. If these files do not exist,
277: it means nothing needs to be added for a given target or
278: host.
279:
280: 5. Make sure the Bison parser generator is installed. (This is
281: unnecessary if the Bison output files `c-parse.c' and `cexp.c'
282: are more recent than `c-parse.y' and `cexp.y' and you do not plan
283: to change the `.y' files.)
284:
285: Bison versions older than Sept 8, 1988 will produce incorrect
286: output for `c-parse.c'.
287:
288: 6. Build the compiler. Just type `make LANGUAGES=c' in the compiler
289: directory.
290:
291: `LANGUAGES=c' specifies that only the C compiler should be
292: compiled. The makefile normally builds compilers for all the
293: supported languages; currently, C, C++ and Objective C. However,
294: C is the only language that is sure to work when you build with
295: other non-GNU C compilers. In addition, building anything but C
296: at this stage is a waste of time.
297:
298: In general, you can specify the languages to build by typing
299: the argument `LANGUAGES="LIST"', where LIST is one or more words
300: from the list `c', `c++', and `objective-c'.
301:
302: Ignore any warnings you may see about "statement not reached"
303: in `insn-emit.c'; they are normal. Any other compilation errors
304: may represent bugs in the port to your machine or operating
305: system, and should be investigated and reported (*note Bugs::.).
306:
307: Some commercial compilers fail to compile GNU CC because they
308: have bugs or limitations. For example, the Microsoft compiler is
309: said to run out of macro space. Some Ultrix compilers run out of
310: expression space; then you need to break up the statement where
311: the problem happens.
312:
313: 7. If you are using COFF-encapsulation, you must convert `libgcc.a'
314: to a GNU-format library at this point. See the file
315: `README-ENCAP' in the directory containing the GNU binary file
316: utilities, for directions.
317:
318: 8. Move the first-stage object files and executables into a
319: subdirectory with this command:
320:
321: make stage1
322:
323: The files are moved into a subdirectory named `stage1'. Once
324: installation is complete, you may wish to delete these files with
325: `rm -r stage1'.
326:
327: 9. Recompile the compiler with itself, with this command:
328:
329: make CC=stage1/gcc CFLAGS="-g -O -Bstage1/"
330:
331: This is called making the stage 2 compiler.
332:
333: The command shown above builds compilers for all the supported
334: languages. If you don't want them all, you can specify the
335: languages to build by typing the argument `LANGUAGES="LIST"'.
336: LIST should contain one or more words from the list `c', `c++',
337: and `objective-c', separated by spaces.
338:
339: On a 68000 or 68020 system lacking floating point hardware,
340: unless you have selected a `tm.h' file that expects by default
341: that there is no such hardware, do this instead:
342:
343: make CC=stage1/gcc CFLAGS="-g -O -Bstage1/ -msoft-float"
344:
345: 10. If you wish to test the compiler by compiling it with itself one
346: more time, do this:
347:
348: make stage2
349: make CC=stage2/gcc CFLAGS="-g -O -Bstage2/"
350:
351: This is called making the stage 3 compiler. Aside from the `-B'
352: option, the options should be the same as when you made the stage
353: 2 compiler.
354:
355: Then compare the latest object files with the stage 2 object
356: files--they ought to be identical, unless they contain time
357: stamps. On systems where object files do not contain time
358: stamps, you can do this (in Bourne shell):
359:
360: for file in *.o; do
361: cmp $file stage2/$file
362: done
363:
364: This will mention any object files that differ between stage 2
365: and stage 3. Any difference, no matter how innocuous, indicates
366: that the stage 2 compiler has compiled GNU CC incorrectly, and is
367: therefore a potentially serious bug which you should investigate
368: and report (*note Bugs::.).
369:
1.1.1.2 ! root 370: On systems that use COFF object files, or an object file
! 371: format that is a superset of COFF (such as ECOFF or XCOFF), bytes
! 372: 5 to 8 will always be different, since it is a timestamp. On
! 373: these systems, you can do the comparison as follows (in Bourne
! 374: shell):
1.1 root 375:
376: for file in *.o; do
377: tail +10c $file > foo1
378: tail +10c stage2/$file > foo2
379: cmp foo1 foo2 || echo $file
380: done
381:
1.1.1.2 ! root 382: If you have built the compiler with the `-mno-mips-tfile'
! 383: option on MIPS machines, you will not be able to compare the
! 384: files.
1.1 root 385:
386: 11. Install the compiler driver, the compiler's passes and run-time
387: support. You can use the following command:
388:
389: make CC=stage2/gcc install
390:
391: (Use the same value for `CC' that you used when compiling the
392: files that are being installed.)
393:
394: This copies the files `cc1', `cpp' and `libgcc.a' to files
395: `cc1', `cpp' and `libgcc.a' in directory
1.1.1.2 ! root 396: `/usr/local/lib/gcc-lib/TARGET/VERSION', which is where the
! 397: compiler driver program looks for them. Here TARGET is the target
! 398: machine type specified when you ran `configure', and VERSION is
! 399: the version number of GNU CC. This naming scheme permits various
1.1 root 400: versions and/or cross-compilers to coexist.
401:
402: It also copies the driver program `gcc' into the directory
403: `/usr/local/bin', so that it appears in typical execution search
404: paths.
405:
406: *Warning: there is a bug in `alloca' in the Sun library. To
1.1.1.2 ! root 407: avoid this bug, be sure to install the executables of GNU CC that
! 408: were compiled by GNU CC. (That is, the executables from stage 2
! 409: or 3, not stage 1.) They use `alloca' as a built-in function and
! 410: never the one in the library.*
! 411:
! 412: (It is usually better to install GNU CC executables from stage
! 413: 2 or 3, since they usually run faster than the ones compiled with
! 414: some other compiler.)
1.1 root 415:
416: 12. If you will be using C++ or Objective C, and your operating
417: system does not handle constructors, then you must build and
418: install the program `collect2'. Do this with the following
419: command:
420:
421: make CC="stage2/gcc -O" install-collect2
422:
423: The systems that *do* handle constructors on their own include
424: system V release 4, and system V release 3 on the Intel 386.
425:
426: Berkeley systems that use the "a.out" object file format handle
427: constructors without `collect2' if you use the GNU linker. But if
428: you don't use the GNU linker, then you need `collect2' on these
429: systems.
430:
431: 13. Build and install `protoize' if you want it. Type
432:
433: make CC="stage2/gcc -O" install-proto
434:
435: There is as yet no documentation for `protoize'. Sorry.
436:
437: 14. Correct errors in the header files on your machine.
438:
439: Various system header files often contain constructs which are
440: incompatible with ANSI C, and they will not work when you compile
441: programs with GNU CC. This behavior consists of substituting for
442: macro argument names when they appear inside of character
443: constants. The most common offender is `ioctl.h'.
444:
445: You can overcome this problem when you compile by specifying
446: the `-traditional' option.
447:
448: Alternatively, on Sun systems and 4.3BSD at least, you can
449: correct the include files by running the shell script
450: `fixincludes'. This installs modified, corrected copies of the
451: files `ioctl.h', `ttychars.h' and many others, in a special
452: directory where only GNU CC will normally look for them. This
453: script will work on various systems because it chooses the files
454: by searching all the system headers for the problem cases that we
455: know about.
456:
457: Use the following command to do this:
458:
459: make install-fixincludes
460:
461: If you selected a different directory for GNU CC installation
462: when you installed it, by specifying the Make variable `prefix' or
463: `libdir', specify it the same way in this command.
464:
465: Note that some systems are starting to come with ANSI C system
466: header files. On these systems, don't run `fixincludes'; it may
467: not work, and is certainly not necessary.
468:
469: If you cannot install the compiler's passes and run-time support in
470: `/usr/local/lib', you can alternatively use the `-B' option to specify
471: a prefix by which they may be found. The compiler concatenates the
472: prefix with the names `cpp', `cc1' and `libgcc.a'. Thus, you can put
473: the files in a directory `/usr/foo/gcc' and specify `-B/usr/foo/gcc/'
474: when you run GNU CC.
475:
476: Also, you can specify an alternative default directory for these
477: files by setting the Make variable `libdir' when you make GNU CC.
478:
479:
480: Compilation in a Separate Directory
481: ===================================
482:
483: If you wish to build the object files and executables in a directory
484: other than the one containing the source files, here is what you must
485: do differently:
486:
487: 1. Make sure you have a version of Make that supports the `VPATH'
488: feature. (GNU Make supports it, as do Make versions on most BSD
489: systems.)
490:
1.1.1.2 ! root 491: 2. If you have ever run `configure' in the source directory, you
! 492: must undo the configuration. Do this by running:
! 493:
! 494: make cleanconfig
! 495:
! 496: 3. Go to the directory in which you want to build the compiler before
! 497: running `configure':
1.1 root 498:
499: mkdir gcc-sun3
500: cd gcc-sun3
501:
502: On systems that do not support symbolic links, this directory
503: must be on the same file system as the source code directory.
504:
1.1.1.2 ! root 505: 4. Specify where to find `configure' when you run it:
1.1 root 506:
507: ../gcc-2.00/configure ...
508:
509: This also tells `configure' where to find the compiler sources;
510: `configure' takes the directory from the file name that was used
511: to invoke it. But if you want to be sure, you can specify the
512: source directory with the `--srcdir' option, like this:
513:
514: ../gcc-2.00/configure --srcdir=../gcc-2.00 sun3
515:
516: The directory you specify with `--srcdir' need not be the same
517: as the one that `configure' is found in.
518:
519: Now, you can run `make' in that directory. You need not repeat the
520: configuration steps shown above, when ordinary source files change.
521: You must, however, run `configure' again when the configuration files
522: change, if your system does not support symbolic links.
523:
524:
525: Installing GNU CC on the Sun
526: ============================
527:
528: Make sure the environment variable `FLOAT_OPTION' is not set when
529: you compile `libgcc.a'. If this option were set to `f68881' when
530: `libgcc.a' is compiled, the resulting code would demand to be linked
531: with a special startup file and would not link properly without
532: special pains.
533:
534: There is a bug in `alloca' in certain versions of the Sun library.
535: To avoid this bug, install the binaries of GNU CC that were compiled by
536: GNU CC. They use `alloca' as a built-in function and never the one in
537: the library.
538:
539: Some versions of the Sun compiler crash when compiling GNU CC. The
540: problem is a segmentation fault in cpp. This problem seems to be due
541: to the bulk of data in the environment variables. You may be able to
542: avoid it by using the following command to compile GNU CC with Sun CC:
543:
544: make CC="TERMCAP=x OBJS=x LIBFUNCS=x STAGESTUFF=x cc"
545:
546:
547: Installing GNU CC on the 3b1
548: ============================
549:
550: Installing GNU CC on the 3b1 is difficult if you do not already have
551: GNU CC running, due to bugs in the installed C compiler. However, the
552: following procedure might work. We are unable to test it.
553:
554: 1. Comment out the `#include "config.h"' line on line 37 of `cccp.c'
555: and do `make cpp'. This makes a preliminary version of GNU cpp.
556:
557: 2. Save the old `/lib/cpp' and copy the preliminary GNU cpp to that
558: file name.
559:
560: 3. Undo your change in `cccp.c', or reinstall the original version,
561: and do `make cpp' again.
562:
563: 4. Copy this final version of GNU cpp into `/lib/cpp'.
564:
565: 5. Replace every occurrence of `obstack_free' in the file `tree.c'
566: with `_obstack_free'.
567:
568: 6. Run `make' to get the first-stage GNU CC.
569:
570: 7. Reinstall the original version of `/lib/cpp'.
571:
572: 8. Now you can compile GNU CC with itself and install it in the
573: normal fashion.
574:
575:
576: Installing GNU CC on Unos
577: =========================
578:
579: Use `configure unos' for building on Unos.
580:
581: The Unos assembler is named `casm' instead of `as'. For some
582: strange reason linking `/bin/as' to `/bin/casm' changes the behavior,
583: and does not work. So, when installing GNU CC, you should install the
584: following script as `as' in the subdirectory where the passes of GCC
585: are installed:
586:
587: #!/bin/sh
588: casm $*
589:
590: The default Unos library is named `libunos.a' instead of `libc.a'.
591: To allow GNU CC to function, either change all references to `-lc' in
592: `gcc.c' to `-lunos' or link `/lib/libc.a' to `/lib/libunos.a'.
593:
594: When compiling GNU CC with the standard compiler, to overcome bugs
595: in the support of `alloca', do not use `-O' when making stage 2. Then
596: use the stage 2 compiler with `-O' to make the stage 3 compiler. This
597: compiler will have the same characteristics as the usual stage 2
598: compiler on other systems. Use it to make a stage 4 compiler and
599: compare that with stage 3 to verify proper compilation.
600:
601: Unos uses memory segmentation instead of demand paging, so you will
602: need a lot of memory. 5 Mb is barely enough if no other tasks are
603: running. If linking `cc1' fails, try putting the object files into a
604: library and linking from that library.
605:
606:
607: Installing GNU CC on VMS
608: ========================
609:
610: The VMS version of GNU CC is distributed in a backup saveset
611: containing both source code and precompiled binaries.
612:
613: To install the `gcc' command so you can use the compiler easily, in
614: the same manner as you use the VMS C compiler, you must install the
615: VMS CLD file for GNU CC as follows:
616:
617: 1. Define the VMS logical names `GNU_CC' and `GNU_CC_INCLUDE' to
618: point to the directories where the GNU CC executables (`gcc-cpp',
619: `gcc-cc1', etc.) and the C include files are kept. This should
620: be done with the commands:
621:
1.1.1.2 ! root 622: $ assign /system /translation=concealed -
! 623: disk:[gcc.] gnu_cc
! 624: $ assign /system /translation=concealed -
! 625: disk:[gcc.include.] gnu_cc_include
1.1 root 626:
627: with the appropriate disk and directory names. These commands
628: can be placed in your system startup file so they will be
629: executed whenever the machine is rebooted. You may, if you
630: choose, do this via the `GCC_INSTALL.COM' script in the `[GCC]'
631: directory.
632:
633: 2. Install the `GCC' command with the command line:
634:
1.1.1.2 ! root 635: $ set command /table=sys$common:[syslib]dcltables -
! 636: /output=sys$common:[syslib]dcltables gnu_cc:[000000]gcc
! 637: $ install replace sys$common:[syslib]dcltables
1.1 root 638:
639: 3. To install the help file, do the following:
640:
641: $ lib/help sys$library:helplib.hlb gcc.hlp
642:
643: Now you can invoke the compiler with a command like `gcc /verbose
644: file.c', which is equivalent to the command `gcc -v -c file.c' in
645: Unix.
646:
647: If you wish to use GNU C++ you must first install GNU CC, and then
648: perform the following steps:
649:
650: 1. Define the VMS logical name `GNU_GXX_INCLUDE' to point to the
651: directory where the preprocessor will search for the C++ header
652: files. This can be done with the command:
653:
1.1.1.2 ! root 654: $ assign /system /translation=concealed -
! 655: disk:[gcc.gxx_include.] gnu_gxx_include
1.1 root 656:
657: with the appropriate disk and directory name. If you are going
1.1.1.2 ! root 658: to be using libg++, this is where the libg++ install procedure
! 659: will install the libg++ header files.
1.1 root 660:
661: 2. Obtain the file `gcc-cc1plus.exe', and place this in the same
662: directory that `gcc-cc1.exe' is kept.
663:
664: The GNU C++ compiler can be invoked with a command like `gcc
665: /plus /verbose file.cc', which is equivalent to the command `g++
666: -v -c file.cc' in Unix.
667:
668: We try to put corresponding binaries and sources on the VMS
669: distribution tape. But sometimes the binaries will be from an older
670: version that the sources, because we don't always have time to update
671: them. (Use the `/version' option to determine the version number of
672: the binaries and compare it with the source file `version.c' to tell
673: whether this is so.) In this case, you should use the binaries you
674: get to recompile the sources. If you must recompile, here is how:
675:
676: 1. Copy the file `vms.h' to `tm.h', `xm-vms.h' to `config.h',
677: `vax.md' to `md.' and `vax.c' to `aux-output.c'. The files to be
678: copied are found in the subdirectory named `config'; they should
679: be copied to the main directory of GNU CC. If you wish, you may
680: use the command file `config-gcc.com' to perform these steps for
681: you.
682:
683: 2. Setup the logical names and command tables as defined above. In
684: addition, define the VMS logical name `GNU_BISON' to point at the
685: to the directories where the Bison executable is kept. This
686: should be done with the command:
687:
1.1.1.2 ! root 688: $ assign /system /translation=concealed -
! 689: disk:[bison.] gnu_bison
1.1 root 690:
691: You may, if you choose, use the `INSTALL_BISON.COM' script in
692: the `[BISON]' directory.
693:
694: 3. Install the `BISON' command with the command line:
695:
1.1.1.2 ! root 696: $ set command /table=sys$common:[syslib]dcltables -
! 697: /output=sys$common:[syslib]dcltables -
! 698: gnu_bison:[000000]bison
! 699: $ install replace sys$common:[syslib]dcltables
1.1 root 700:
701: 4. Type `@make-gcc' to recompile everything (alternatively, you may
702: submit the file `make-gcc.com' to a batch queue). If you wish to
703: build the GNU C++ compiler as well as the GNU CC compiler, you
704: must first edit `make-gcc.com' and follow the instructions that
705: appear in the comments.
706:
1.1.1.2 ! root 707: 5. In order to use GCC, you need a library of functions which GCC
! 708: compiled code will call to perform certain tasks, and these
! 709: functions are defined in the file `libgcc2.c'. To compile this
! 710: you should use the command procedure `make-l2.com', which will
! 711: generate the library `libgcc2.olb'. `libgcc2.olb' should be
! 712: built using the compiler built from the same distribution that
! 713: `libgcc2.c' came from, and `make-gcc.com' will automatically do
! 714: all of this for you.
! 715:
! 716: To install the library, use the following commands:
! 717:
! 718: $ lib gnu_cc:[000000]gcclib/delete=(new,eprintf)
! 719: $ lib libgcc2/extract=*/output=libgcc2.obj
! 720: $ lib gnu_cc:[000000]gcclib libgcc2.obj
! 721:
! 722: The first command simply removes old modules that will be
! 723: replaced with modules from libgcc2. If the VMS librarian
! 724: complains about those modules not being present, simply ignore
! 725: the message and continue on with the next command.
! 726:
! 727: Whenever you update the compiler on your system, you should
! 728: also update the library with the above procedure.
! 729:
1.1 root 730: *If you are building GNU CC with a previous version of GNU CC,
731: you also should check to see that you have the newest version of
732: the assembler*. In particular, GNU CC version 2 treats global
733: constant variables slightly differently from GNU CC version 1,
734: and GAS version 1.38.1 does not have the patches required to work
735: with GCC version 2. If you use GAS 1.38.1, then `extern const'
736: variables will not have the read-only bit set, and the linker
737: will generate warning messages about mismatched psect attributes
738: for these variables. These warning messages are merely a
739: nuisance, and can safely be ignored.
740:
741: If you are compiling with a version of GNU CC older than 1.33,
742: specify `/DEFINE=("inline=")' as an option in all the
743: compilations. This requires editing all the `gcc' commands in
744: `make-cc1.com'. (The older versions had problems supporting
745: `inline'.) Once you have a working 1.33 or newer GNU CC, you can
746: change this file back.
747:
748: Under previous versions of GNU CC, the generated code would
749: occasionally give strange results when linked to the sharable
750: `VAXCRTL' library. Now this should work.
751:
752: Even with this version, however, GNU CC itself should not be linked
753: to the sharable `VAXCRTL'. The `qsort' routine supplied with
754: `VAXCRTL' has a bug which can cause a compiler crash.
755:
756: Similarly, the preprocessor should not be linked to the sharable
757: `VAXCRTL'. The `strncat' routine supplied with `VAXCRTL' has a bug
758: which can cause the preprocessor to go into an infinite loop.
759:
760: If you attempt to link to the sharable `VAXCRTL', the VMS linker
761: will strongly resist any effort to force it to use the `qsort' and
762: `strncat' routines from `gcclib'. Until the bugs in `VAXCRTL' have
763: been fixed, linking any of the compiler components to the sharable
764: VAXCRTL is not recommended. (These routines can be bypassed by
765: placing duplicate copies of `qsort' and `strncat' in `gcclib' under
766: different names, and patching the compiler sources to use these
767: routines). Both of the bugs in `VAXCRTL' are still present in VMS
768: version 5.4-1, which is the most recent version as of this writing.
769:
770: The executables that are generated by `make-cc1.com' and
771: `make-cccp.com' use the nonshared version of `VAXCRTL' (and thus use
772: the `qsort' and `strncat' routines from `gcclib.olb').
1.1.1.2 ! root 773:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.