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