![[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.