|
|
1.1.1.15! root 1: This is a copy of one node from the Info file gcc.info-3. 1.1 root 2: For full information on installing and porting GCC, refer to the 1.1.1.6 root 3: GCC manual: 1.1 root 4: 1.1.1.6 root 5: Info file gcc.info 6: TeX output gcc.dvi 7: TeX source gcc.texinfo 8: 1.1 root 9: Installing GNU CC 10: ***************** 11: 12: Here is the procedure for installing GNU CC on a Unix system. 13: 14: * Menu: 15: 1.1.1.12 root 16: * Other Dir:: Compiling in a separate directory (not where the source is). 17: * Sun Install:: See below for installation on the Sun. 18: * 3B1 Install:: See below for installation on the 3B1. 1.1.1.15! root 19: * SCO Install:: See below for installation on SCO System V 3.2. (Or ESIX.) 1.1 root 20: * VMS Install:: See below for installation on VMS. 1.1.1.13 root 21: * HPUX Install:: See below for installation on HPUX. 1.1.1.14 root 22: * MIPS Install:: See below for installation on MIPS. 1.1.1.15! root 23: * Tower Install:: See below for installation on an NCR Tower. 1.1 root 24: 1.1.1.4 root 25: 1. Edit `Makefile'. If you are using HPUX, or any form of system 26: V, you must make a few changes described in comments at the 1.1.1.13 root 27: beginning of the file. Genix requires changes also, and so does 28: the Pyramid. 1.1.1.2 root 29: 30: 2. On a Sequent system, go to the Berkeley universe. 1.1 root 31: 1.1.1.7 root 32: 3. Choose configuration files. The easy way to do this is to run 1.1.1.12 root 33: the command file `config.gcc' with a single argument, which 34: specifies the type of machine (and in some cases which operating 35: system). 1.1.1.7 root 36: 1.1.1.8 root 37: Here is a list of the possible arguments: 38: 39: `vax' 40: Vaxes running BSD. 41: 42: `vms' 43: Vaxes running VMS. 44: 45: `vax-sysv' 46: Vaxes running system V. 47: 48: `i386-sysv' 49: Intel 386 PCs running system V. 50: 1.1.1.9 root 51: `i386-sysv-gas' 52: Intel 386 PCs running system V, using the GNU assembler and 53: GNU linker. 54: 1.1.1.10 root 55: `sequent-i386' 1.1.1.8 root 56: Sequent with Intel 386 processors. 57: 1.1.1.12 root 58: `i386-aix' 59: Intel 386 PCs or PS/2s running AIX. 60: 1.1.1.8 root 61: `sun2' 62: Sun 2 running system version 2 or 3. 63: 64: `sun3' 1.1.1.12 root 65: Sun 3 running system version 2 or 3, with 68881. Note 66: there we do not provide a configuration file to use an FPA 67: by default, because programs that establish signal handlers 68: for floating point traps inherently cannot work with the FPA. 1.1.1.11 root 69: 1.1.1.9 root 70: `sun3-nfp' 71: Sun 3 running system version 2 or 3, without 68881. 72: 1.1.1.8 root 73: `sun4' 1.1.1.12 root 74: Sun 4 running system version 2 or 3. *Note 75: Incompatibilities::, for calling convention 76: incompatibilities on the Sun 4 (sparc). 1.1.1.8 root 77: 78: `sun2-os4' 79: Sun 2 running system version 4. 80: 81: `sun3-os4' 1.1.1.9 root 82: Sun 3 running system version 4, with 68881. 83: 84: `sun3-nfp-os4' 85: Sun 3 running system version 4, without 68881. 86: 1.1.1.8 root 87: `sun4-os4' 1.1.1.12 root 88: Sun 4 running system version 4. *Note Incompatibilities::, 89: for calling convention incompatibilities on the Sun 4 90: (sparc). 1.1.1.8 root 91: 92: `sun386' 1.1.1.14 root 93: Sun 386 ("roadrunner"). 1.1.1.8 root 94: 1.1.1.9 root 95: `alliant' 1.1.1.12 root 96: Alliant FX/8 computer. Note that the standard installed C 97: compiler in Concentrix 5.0 has a bug which prevent it from 98: compiling GNU CC correctly. You can patch the compiler bug 99: as follows: 100: 101: cp /bin/pcc ./pcc 1.1.1.13 root 102: adb -w ./pcc - << EOF 1.1.1.12 root 103: 15f6?w 6610 104: EOF 105: 106: Then you must use the `-ip12' option when compiling GNU CC 107: with the patched compiler, as shown here: 108: 109: make CC="./pcc -ip12" CFLAGS=-w 110: 111: Note also that Alliant's version of DBX does not manage to 112: work with the output from GNU CC. 113: 114: `tahoe' 115: The tahoe computer (running BSD, and using DBX). 116: 117: `decstation' 1.1.1.14 root 118: The DEC 3100 Mips machine ("pmax"). Note that GNU CC 1.1.1.12 root 119: cannot generate debugging information in the unusual format 120: used on the Mips. 121: 122: `mips-sysv' 123: The Mips computer, RS series, with the System V environment 124: as default. Note that GNU CC cannot generate debugging 125: information in the unusual format used on the Mips. 126: 127: `mips-bsd43' 128: The Mips computer, RS series, with the BSD 4.3 environment 129: as default. Note that GNU CC cannot generate debugging 130: information in the unusual format used on the Mips. 1.1.1.9 root 131: 1.1.1.11 root 132: `mips' 1.1.1.12 root 133: The Mips computer, M series. Note that GNU CC cannot 134: generate debugging information in the unusual format used 135: on the Mips. 136: 137: `iris' 1.1.1.14 root 138: Another variant of the Mips computer, the Silicon Graphics 139: Iris 4D. Note that GNU CC cannot generate debugging 140: information in the unusual format used on the Mips. 1.1.1.11 root 141: 1.1.1.9 root 142: `convex-c1' 143: Convex C1 computer. 144: 145: `convex-c2' 146: Convex C2 computer. 147: 1.1.1.12 root 148: `pyramid' 149: Pyramid computer. 150: 1.1.1.8 root 151: `hp9k320' 1.1.1.11 root 152: HP 9000 series 300 using HPUX assembler. Note there is no 153: support in GNU CC for HP's debugger; thus, `-g' is not 154: available in this configuration. 1.1.1.8 root 155: 1.1.1.12 root 156: `hp9k320-gas' 1.1.1.8 root 157: HP 9000 series 300 using GNU assembler, linker and debugger. 1.1.1.11 root 158: This requires the HP-adapt package, which is available 1.1.1.14 root 159: along with the GNU linker as part of the "binutils" 1.1.1.11 root 160: distribution. This is on the GNU CC distribution tape. 1.1.1.8 root 161: 1.1.1.12 root 162: `hp9k320-old' 163: HP 9000 series 300 using HPUX assembler, in operating 164: system versions older than 6.5. Note there is no support 165: in GNU CC for HP's debugger; thus, `-g' is not available in 166: this configuration. 167: 168: `hp9k320-bsd' 169: HP 9000 series 300 running BSD. 170: 1.1.1.8 root 171: `isi68' 1.1.1.12 root 172: ISI 68000 or 68020 system with a 68881. 173: 174: `isi68-nfp' 175: ISI 68000 or 68020 system without a 68881. 1.1.1.8 root 176: 177: `news800' 178: Sony NEWS 68020 system. 179: 1.1.1.10 root 180: `next' 181: NeXT system. 182: 1.1.1.14 root 183: `tower' 184: NCR Tower 32 system. 185: 1.1.1.11 root 186: `altos' 187: Altos 3068. Note that you must use the GNU assembler, 188: linker and debugger, with COFF-encapsulation. Also, you 189: must fix a kernel bug. Details in the file `ALTOS-README'. 190: 1.1.1.8 root 191: `3b1' 1.1.1.12 root 192: AT&T 3b1, a.k.a. 7300 PC. Note that special procedures are 193: needed to compile GNU CC with this machine's standard C 194: compiler, due to bugs in that compiler. *Note 3b1 195: Install::. You can bootstrap it more easily with previous 196: versions of GNU CC if you have them. 1.1.1.8 root 197: 1.1.1.13 root 198: `3b1-gas' 199: AT&T 3b1 using the GNU assembler. 200: 1.1.1.8 root 201: `sequent-ns32k' 202: Sequent containing ns32000 processors. 203: 204: `encore' 205: Encore ns32000 system. 206: 207: `genix' 208: National Semiconductor ns32000 system. 209: 210: `88000' 211: Motorola 88000 processor. This port is not finished. 212: 213: Here we spell out what files need to be set up: 1.1 root 214: 1.1.1.4 root 215: * Make a symbolic link named `config.h' to the top-level 216: config file for the machine you are using (*note 217: Config::.). This file is responsible for defining 218: information about the host machine. It includes `tm.h'. 219: 1.1.1.11 root 220: The file is located in the subdirectory `config'. Its name 221: should be `xm-MACHINE.h', with these exceptions: 1.1.1.4 root 222: 1.1.1.8 root 223: `xm-vms.h' 1.1.1.4 root 224: for vaxen running VMS. 225: 1.1.1.8 root 226: `xm-vaxv.h' 1.1.1.4 root 227: for vaxen running system V. 228: 1.1.1.8 root 229: `xm-i386v.h' 1.1.1.4 root 230: for Intel 80386's running system V. 231: 1.1.1.8 root 232: `xm-sun386i.h' 233: for Sun roadrunner running any version of the 234: operating system. 235: 236: `xm-hp9k320.h' 1.1.1.4 root 237: for the HP 9000 series 300. 238: 1.1.1.8 root 239: `xm-genix.h' 1.1.1.4 root 240: for the ns32000 running Genix 241: 242: If your system does not support symbolic links, you might 243: want to set up `config.h' to contain a `#include' command 244: which refers to the appropriate file. 245: 246: * Make a symbolic link named `tm.h' to the 1.1.1.11 root 247: machine-description macro file for your machine. It should 248: be in the subdirectory `config' and its name should be 249: `tm-MACHINE.h'. 1.1.1.4 root 250: 251: If your system is a 68000, don't use the file `tm-m68k.h' 252: directly. Instead, use one of these files: 253: 254: `tm-sun3.h' 1.1.1.9 root 255: for Sun 3 machines with 68881. 256: 257: `tm-sun3-nfp.h' 258: for Sun 3 machines with no hardware floating point. 1.1.1.4 root 259: 1.1.1.12 root 260: `tm-sun3os3.h' 261: for Sun 3 machines with 68881, running Sunos version 3. 262: 263: `tm-sun3os3nf.h' 264: for Sun 3 machines with no hardware floating point, 265: running Sunos version 3. 266: 1.1.1.4 root 267: `tm-sun2.h' 268: for Sun 2 machines. 269: 270: `tm-3b1.h' 271: for AT&T 3b1 (aka 7300 Unix PC). 272: 273: `tm-isi68.h' 1.1.1.8 root 274: for Integrated Solutions systems. This file assumes 275: you use the GNU assembler. 1.1.1.4 root 276: 1.1.1.12 root 277: `tm-isi68-nfp.h' 278: for Integrated Solutions systems without a 68881. 279: This file assumes you use the GNU assembler. 280: 1.1.1.4 root 281: `tm-news800.h' 1.1.1.12 root 282: for Sony NEWS systems. 1.1.1.4 root 283: 284: `tm-hp9k320.h' 285: for HPUX systems, if you are using GNU CC with the 286: system's assembler and linker. 287: 288: `tm-hp9k320g.h' 289: for HPUX systems, if you are using the GNU assembler, 290: linker and other utilities. Not all of the pieces of 291: GNU software needed for this mode of operation are as 292: yet in distribution; full instructions will appear 293: here in the future. 294: 1.1.1.14 root 295: `tm-tower-as.h' 296: for NCR Tower 32 systems, using the standard system 297: assembler. 298: 1.1.1.4 root 299: For the vax, use `tm-vax.h' on BSD Unix, `tm-vaxv.h' on 300: system V, or `tm-vms.h' on VMS. 301: 302: For the Motorola 88000, use `tm-m88k.h'. The support for 1.1.1.13 root 303: the 88000 does not currently work; it requires extensive 304: changes which we hope to reconcile in version 2. 1.1.1.4 root 305: 306: For the 80386, don't use `tm-i386.h' directly. Use 307: `tm-i386v.h' if the target machine is running system V, 1.1.1.9 root 308: `tm-i386gas.h' if it is running system V but you are using 309: the GNU assembler and linker, `tm-seq386.h' for a Sequent 310: 386 system, or `tm-compaq.h' for a Compaq, or 311: `tm-sun386i.h' for a Sun 386 system. 1.1.1.4 root 312: 1.1.1.12 root 313: For the Mips computer, there are five choices: `tm-mips.h' 314: for the M series, `tm-mips-bsd.h' for the RS series with 315: BSD, `tm-mips-sysv.h' for the RS series with System V, 316: `tm-iris.h' for the Iris version of the machine, and 317: `tm-decstatn.h' for the Decstation. 318: 1.1.1.4 root 319: For the 32000, use `tm-sequent.h' if you are using a 320: Sequent machine, or `tm-encore.h' for an Encore machine, or 1.1.1.8 root 321: `tm-genix.h' if you are using Genix version 3; otherwise, 1.1.1.4 root 322: perhaps `tm-ns32k.h' will work for you. 323: 324: Note that Genix has bugs in `alloca' and `malloc'; you must 325: get the compiled versions of these from GNU Emacs and edit 326: GNU CC's `Makefile' to use them. 1.1 root 327: 1.1.1.2 root 328: Note that Encore systems are supported only under BSD. 1.1 root 329: 1.1.1.10 root 330: For Sparc (Sun 4) machines, use `tm-sparc.h' with operating 331: system version 4, and `tm-sun4os3.h' with system version 3. 332: 1.1.1.14 root 333: For Convex systems before version 8.1, use `tm-conv1os7.h' 334: or `tm-conv2os7.h'. For versions 8.1 and greater, use 335: `tm-convex1.h' or `tm-convex2.h'. You should also 336: bootstrap GCC with `pcc' rather than `cc'; one way to do 337: this is with the following commands. 338: 339: ln -s /bin/pcc ./cc 340: set path = (. $path) 341: 1.1 root 342: * Make a symbolic link named `md' to the machine description 1.1.1.11 root 343: pattern file. It should be in the `config' subdirectory 344: and its name should be `MACHINE.md'; but MACHINE is often 345: not the same as the name used in the `tm.h' file because 346: the `md' files are more general. 1.1 root 347: 348: * Make a symbolic link named `aux-output.c' to the output 1.1.1.11 root 349: subroutine file for your machine. It should be in the 350: `config' subdirectory and its name should be `out-MACHINE.c'. 1.1 root 351: 1.1.1.4 root 352: 4. Make sure the Bison parser generator is installed. (This is 353: unnecessary if the Bison output files `c-parse.tab.c' and 354: `cexp.c' are more recent than `c-parse.y' and `cexp.y' and you 355: do not plan to change the `.y' files.) 356: 1.1.1.13 root 357: Bison versions older than Sept 8, 1988 will produce incorrect 1.1.1.5 root 358: output for `c-parse.tab.c'. 1.1 root 359: 1.1.1.14 root 360: 5. If you have a previous version of GCC installed, then chances 361: are you can compile the new version with that. Do the following: 362: 363: make CC="gcc -O" 364: 365: Since this produces an optimized executable right away, there is 366: no need to bootstrap the result with itself except to test it. 367: Therefore, you can skip directly to the `make install' step below. 1.1 root 368: 1.1.1.14 root 369: 6. Build the compiler. Just type `make' in the compiler directory. 370: 371: Ignore any warnings you may see about "statement not reached" in 372: the `insn-emit.c'; they are normal. Any other compilation 1.1.1.7 root 373: errors may represent bugs in the port to your machine or 374: operating system, and should be investigated and reported (*note 375: Bugs::.). 376: 1.1.1.13 root 377: Some commercial compilers fail to compile GNU CC because they 378: have bugs or limitations. For example, the Microsoft compiler 379: is said to run out of macro space. Some Ultrix compilers run 380: out of expression space; then you need to break up the statement 381: where the problem happens. 1.1.1.11 root 382: 1.1.1.14 root 383: 7. If you are using COFF-encapsulation, you must convert `gnulib' 1.1.1.9 root 384: to a GNU-format library at this point. See the file 385: `README-ENCAP' in the directory containing the GNU binary file 386: utilities, for directions. 387: 1.1.1.14 root 388: 8. Move the first-stage object files and executables into a 1.1.1.4 root 389: subdirectory with this command: 1.1 root 390: 391: make stage1 392: 393: The files are moved into a subdirectory named `stage1'. Once 1.1.1.4 root 394: installation is complete, you may wish to delete these files 395: with `rm -r stage1'. 1.1 root 396: 1.1.1.14 root 397: 9. Recompile the compiler with itself, with this command: 1.1 root 398: 399: make CC=stage1/gcc CFLAGS="-g -O -Bstage1/" 400: 1.1.1.14 root 401: This is called making the stage 2 compiler. 402: 1.1.1.4 root 403: On a 68000 or 68020 system lacking floating point hardware, 404: unless you have selected a `tm.h' file that expects by default 405: that there is no such hardware, do this instead: 1.1 root 406: 407: make CC=stage1/gcc CFLAGS="-g -O -Bstage1/ -msoft-float" 408: 1.1.1.14 root 409: 10. If you wish to test the compiler by compiling it with itself one 1.1.1.11 root 410: more time, do this (in C shell): 1.1 root 411: 412: make stage2 1.1.1.6 root 413: make CC=stage2/gcc CFLAGS="-g -O -Bstage2/" 1.1 root 414: foreach file (*.o) 415: cmp $file stage2/$file 416: end 417: 1.1.1.14 root 418: This is called making the stage 3 compiler. Aside from the `-B' 419: option, the options should be the same as when you made the 420: stage 2 compiler. 1.1.1.4 root 421: 1.1.1.11 root 422: The `foreach' command (written in C shell) will notify you if 423: any of these stage 3 object files differs from those of stage 2. 424: On BSD systems, any difference, no matter how innocuous, 425: indicates that the stage 2 compiler has compiled GNU CC 426: incorrectly, and is therefore a potentially serious bug which 427: you should investigate and report (*note Bugs::.). 428: 429: On systems that use COFF object files, bytes 5 to 8 will always 430: be different, since it is a timestamp. On these systems, you 431: can do the comparison as follows (in Bourne shell): 432: 433: for file in *.o; do 434: echo $file 1.1.1.14 root 435: tail +10c $file > foo1 436: tail +10c stage2/$file > foo2 1.1.1.11 root 437: cmp foo1 foo2 438: done 439: 1.1.1.14 root 440: On MIPS machines, you should use the shell script `ecoff-cmp' to 441: compare two object files. 442: 443: 11. Install the compiler driver, the compiler's passes and run-time 1.1.1.4 root 444: support. You can use the following command: 1.1 root 445: 446: make install 447: 1.1.1.4 root 448: This copies the files `cc1', `cpp' and `gnulib' to files 449: `gcc-cc1', `gcc-cpp' and `gcc-gnulib' in directory 450: `/usr/local/lib', which is where the compiler driver program 451: looks for them. It also copies the driver program `gcc' into 1.1.1.10 root 452: the directory `/usr/local/bin', so that it appears in typical 1.1.1.4 root 453: execution search paths. 454: 455: *Warning: there is a bug in `alloca' in the Sun library. To 456: avoid this bug, install the binaries of GNU CC that were 457: compiled by GNU CC. They use `alloca' as a built-in function 458: and never the one in the library.* 459: 460: *Warning: the GNU CPP may not work for `ioctl.h', `ttychars.h' 461: and other system header files unless the `-traditional' option 462: is used.* The bug is in the header files: at least on some 463: machines, they rely on behavior that is incompatible with ANSI 464: C. This behavior consists of substituting for macro argument 465: names when they appear inside of character constants. The 466: `-traditional' option tells GNU CC to behave the way these 467: headers expect. 1.1 root 468: 1.1.1.4 root 469: Because of this problem, you might prefer to configure GNU CC to 470: use the system's own C preprocessor. To do so, make the file 1.1 root 471: `/usr/local/lib/gcc-cpp' a link to `/lib/cpp'. 472: 1.1.1.4 root 473: Alternatively, on Sun systems and 4.3BSD at least, you can 474: correct the include files by running the shell script 475: `fixincludes'. This installs modified, corrected copies of the 476: files `ioctl.h', `ttychars.h' and many others, in a special 1.1.1.7 root 477: directory where only GNU CC will normally look for them. This 1.1.1.10 root 478: script will work on various systems because it chooses the files 1.1.1.7 root 479: by searching all the system headers for the problem cases that 480: we know about. 1.1 root 481: 1.1.1.14 root 482: Use the following command to do this: 483: 484: make includes 485: 486: If you selected a different directory for GNU CC installation 487: when you installed it, by specifying the Make variable `prefix' 488: or `libdir', specify it the same way in this command. 489: 490: Note that some systems are starting to come with ANSI C system 491: header files. On these systems, don't run `fixincludes'; it may 492: not work, and is certainly not necessary. 493: 1.1 root 494: If you cannot install the compiler's passes and run-time support in 1.1.1.4 root 495: `/usr/local/lib', you can alternatively use the `-B' option to 496: specify a prefix by which they may be found. The compiler 497: concatenates the prefix with the names `cpp', `cc1' and `gnulib'. 498: Thus, you can put the files in a directory `/usr/foo/gcc' and specify 499: `-B/usr/foo/gcc/' when you run GNU CC. 500: 501: Also, you can specify an alternative default directory for these 502: files by setting the Make variable `libdir' when you make GNU CC. 1.1 root 503: 1.1.1.2 root 504: 1.1.1.11 root 505: 1.1.1.12 root 506: File: gcc.info, Node: Other Dir, Next: Sun Install, Prev: Installation, Up: Installation 1.1.1.2 root 507: 1.1.1.12 root 508: Compilation in a Separate Directory 509: =================================== 1.1 root 510: 1.1.1.12 root 511: If you wish to build the object files and executables in a directory 512: other than the one containing the source files, here is what you must 513: do differently: 1.1.1.8 root 514: 1.1.1.12 root 515: 1. Go to that directory before running `config.gcc': 1.1.1.4 root 516: 1.1.1.12 root 517: mkdir gcc-sun3 518: cd gcc-sun3 1.1 root 519: 1.1.1.12 root 520: On systems that do not support symbolic links, this directory 521: must be on the same file system as the source code directory. 1.1.1.2 root 522: 1.1.1.12 root 523: 2. Specify where to find `config.gcc' when you run it: 524: 525: ../gcc-1.36/config.gcc ... 526: 527: 3. Specify where to find the sources, as an argument to `config.gcc': 528: 529: ../gcc-1.36/config.gcc -srcdir=../gcc-1.36 sun3 530: 531: The `-srcdir=DIR' option is not needed when the source directory 532: is the parent of the current directory, because `config.gcc' 533: detects that case automatically. 534: 535: Now, you can run `make' in that directory. You need not repeat the 536: configuration steps shown above, when ordinary source files change. 537: You must, however, run `config.gcc' again when the configuration 538: files change, if your system does not support symbolic links. 539: 540: 541: 542: File: gcc.info, Node: Sun Install, Next: 3b1 Install, Prev: Other Dir, Up: Installation 543: 544: Installing GNU CC on the Sun 545: ============================ 546: 547: Make sure the environment variable `FLOAT_OPTION' is not set when you 548: compile `gnulib'. If this option were set to `f68881' when `gnulib' 549: is compiled, the resulting code would demand to be linked with a 550: special startup file and would not link properly without special 551: pains. 552: 553: There is a bug in `alloca' in certain versions of the Sun library. 554: To avoid this bug, install the binaries of GNU CC that were compiled 555: by GNU CC. They use `alloca' as a built-in function and never the 556: one in the library. 557: 1.1.1.15! root 558: Some versions of the Sun compiler crash when compiling GNU CC, with a ! 559: segmentation fault in cpp. This can sometimes be due to the bulk of ! 560: data in the environment variables. You may be able to avoid it by ! 561: using the following command to compile GNU CC with Sun CC: 1.1.1.12 root 562: 563: make CC="TERMCAP=x OBJS=x LIBFUNCS=x STAGESTUFF=x cc" 564: 1.1.1.15! root 565: Another problem that often happens on Suns is that you get a crash ! 566: when building stage 2, when `genflags' is run. ! 567: ! 568: One reason for such as crash is if you configured GNU CC for the ! 569: wrong version of SunOS. Starting with version 1.38, configurations ! 570: `sun3' and `sun4' are for SunOS 4, so this problem should no longer ! 571: happen. ! 572: ! 573: Another cause of the same symptom is having installed the GNU linker ! 574: with an earlier version of SunOS. The version that worked before ! 575: stopped working due to a change in the format of executables in SunOS ! 576: 4.1. Many sites have installed the GNU linker as ! 577: `/usr/local/lib/gcc-ld', often as part of installing GNU C++. So if ! 578: you get such crashes and you have used the proper configuration, try ! 579: deleting `/usr/local/lib/gcc-ld'. ! 580: ! 581: The current version of the GNU linker, found in the current binutils ! 582: release, does work with SunOS 4.1. ! 583: 1.1.1.12 root 584: 585: 1.1.1.14 root 586: File: gcc.info, Node: 3b1 Install, Next: SCO Install, Prev: Sun Install, Up: Installation 1.1.1.12 root 587: 588: Installing GNU CC on the 3b1 589: ============================ 590: 591: Installing GNU CC on the 3b1 is difficult if you do not already have 592: GNU CC running, due to bugs in the installed C compiler. However, 593: the following procedure might work. We are unable to test it. 594: 595: 1. Comment out the `#include "config.h"' line on line 37 of 596: `cccp.c' and do `make cpp'. This makes a preliminary version of 597: GNU cpp. 598: 599: 2. Save the old `/lib/cpp' and copy the preliminary GNU cpp to that 600: file name. 601: 602: 3. Undo your change in `cccp.c', or reinstall the original version, 603: and do `make cpp' again. 604: 605: 4. Copy this final version of GNU cpp into `/lib/cpp'. 606: 1.1.1.13 root 607: 5. Replace every occurrence of `obstack_free' in `tree.c' with 1.1.1.12 root 608: `_obstack_free'. 609: 610: 6. Run `make' to get the first-stage GNU CC. 611: 612: 7. Reinstall the original version of `/lib/cpp'. 613: 614: 8. Now you can compile GNU CC with itself and install it in the 615: normal fashion. 616: 1.1.1.13 root 617: If you have installed an earlier version of GCC, you can compile the 618: newer version with that. However, you will run into trouble 619: compiling `gnulib', since that is normally compiled with CC. To 620: solve the problem, uncomment this line in `Makefile': 621: 622: CCLIBFLAGS = -B/usr/local/lib/gcc- -tp -Wp,-traditional 623: 1.1.1.12 root 624: 625: 1.1.1.14 root 626: File: gcc.info, Node: SCO Install, Next: VMS Install, Prev: 3B1 Install, Up: Installation 627: 628: Installing GNU CC on SCO System V 3.2 629: ===================================== 630: 631: The compiler that comes with this system does not work properly with 632: `-O'. Therefore, you should redefine the Make variable `CCLIBFLAGS' 633: not to use `-O'. 634: 1.1.1.15! root 635: You should also edit `Makefile' to enable the lines that set `CLIB' ! 636: to `-lPW', and the ones specifically labeled as being for SCO, that ! 637: set `RANLIB', and that set `CC' and `OLDCC' to `rcc'. ! 638: ! 639: Also, edit the definition of `USER_H' to remove the file `limits.h'. ! 640: ! 641: Then you can run `config.gcc i386-sco' and finish building GNU CC ! 642: normally. ! 643: ! 644: The same recipe should work on ESIX, but use `config.gcc i386-esix' ! 645: instead. 1.1.1.14 root 646: 647: 648: 649: File: gcc.info, Node: VMS Install, Next: HPUX Install, Prev: SCO Install, Up: Installation 1.1.1.12 root 650: 651: Installing GNU CC on VMS 652: ======================== 1.1.1.9 root 653: 1.1.1.12 root 654: The VMS version of GNU CC is distributed in a backup saveset 655: containing both source code and precompiled binaries. 656: 657: To install the `gcc' command so you can use the compiler easily, in 1.1.1.4 root 658: the same manner as you use the VMS C compiler, you must install the 659: VMS CLD file for GNU CC as follows: 660: 661: 1. Define the VMS logical names `GNU_CC' and `GNU_CC_INCLUDE' to 662: point to the directories where the GNU CC executables 663: (`gcc-cpp', `gcc-cc1', etc.) and the C include files are kept. 664: This should be done with the commands: 1.1.1.2 root 665: 1.1.1.12 root 666: $ assign /super /system disk:[gcc.] gnu_cc 667: $ assign /super /system disk:[gcc.include.] gnu_cc_include 1.1.1.2 root 668: 1.1.1.4 root 669: with the appropriate disk and directory names. These commands 670: can be placed in your system startup file so they will be 1.1.1.12 root 671: executed whenever the machine is rebooted. You may, if you 672: choose, do this via the `GCC_INSTALL.COM' script in the `[GCC]' 673: directory. 1.1.1.2 root 674: 675: 2. Install the `GCC' command with the command line: 676: 1.1.1.12 root 677: $ set command /table=sys$library:dcltables gnu_cc:[000000]gcc 1.1.1.2 root 678: 1.1.1.11 root 679: 3. To install the help file, do the following: 680: 681: $ lib/help sys$library:helplib.hlb gcc.hlp 682: 1.1.1.4 root 683: Now you can invoke the compiler with a command like `gcc 684: /verbose file.c', which is equivalent to the command `gcc -v -c 685: file.c' in Unix. 1.1.1.9 root 686: 1.1.1.12 root 687: We try to put corresponding binaries and sources on the VMS 688: distribution tape. But sometimes the binaries will be from an older 689: version that the sources, because we don't always have time to update 690: them. (Use the `/verbose' option to determine the version number of 691: the binaries and compare it with the source file `version.c' to tell 692: whether this is so.) In this case, you should use the binaries you 693: get to recompile the sources. If you must recompile, here is how: 694: 695: 1. Copy the file `tm-vms.h' to `tm.h', `xm-vms.h' to `config.h', 696: `vax.md' to `md.' and `out-vax.c' to `aux-output.c'. The files 697: to be copied are found in the subdirectory named `config'; they 698: should be copied to the main directory of GNU CC. 699: 700: 2. Setup the logical names and command tables as defined above. In 701: addition, define the vms logical name `GNU_BISON' to point at 702: the to the directories where the Bison executable is kept. This 703: should be done with the command: 704: 705: $ assign /super /system disk:[bison.] gnu_bison 706: 707: You may, if you choose, use the `INSTALL_BISON.COM' script in 708: the `[BISON]' directory. 709: 710: 3. Install the `BISON' command with the command line: 711: 712: $ set command /table=sys$library:dcltables gnu_bison:[000000]bison 713: 714: 4. Type `@make' to do recompile everything. 715: 716: If you are compiling with a version of GNU CC older than 1.33, 717: specify `/DEFINE=("inline=")' as an option in all the 718: compilations. This requires editing all the `gcc' commands in 719: `make-cc1.com'. (The older versions had problems supporting 720: `inline'.) Once you have a working 1.33 or newer GNU CC, you 721: can change this file back. 722: 1.1.1.14 root 723: With this version of GNU CC, `const' global variables now work 724: properly. Unless, however, the `const' modifier is also specified in 725: every external declaration of the variable in all of the source files 726: that use that variable, the linker will issue warnings about 727: conflicting attributes for the variable, since the linker does not 728: know if the variable should be read-only. The program will still 729: work, but the variable will be placed in writable storage. 730: 731: Under previous versions of GNU CC, the generated code would 732: occasionally give strange results when linked to the sharable 733: `VAXCRTL' library. Now this should work. 734: 735: Even with this version, however, GNU CC itself should not be linked 736: to the sharable `VAXCRTL', unless you force the linker to use the 737: `qsort' routine from `gcclib.olb'. The `qsort' routine supplied with 738: `VAXCRTL' has a bug which causes a compiler crash. The executable 739: that is generated by `make-cc1.com' uses the non-shared version of 740: `VAXCRTL' (and thus the `qsort' routine from `gcclib.olb'). 741: 742: Note that GNU CC on VMS now generates debugging information to 743: describe the programs symbols to the VMS debugger. However, you need 744: version 1.37 or later of GAS in order to output them properly in the 745: object file. 1.1.1.13 root 746: 747: 748: 1.1.1.14 root 749: File: gcc.info, Node: HPUX Install, Next: MIPS Install, Prev: VMS Install, Up: Installation 1.1.1.13 root 750: 751: Installing GNU CC on HPUX 752: ========================= 753: 754: To install GNU CC on HPUX, you must start by editing the file 755: `Makefile'. Search for the string `HPUX' to find comments saying 756: what to change. You need to change some variable definitions and (if 757: you are using GAS) some lines in the rule for the target `gnulib'. 758: 1.1.1.14 root 759: To avoid errors when linking programs with `-g', create an empty 760: library named `libg.a'. An easy way to do this is: 761: 762: ar rc /usr/local/lib/libg.a 763: 1.1.1.13 root 764: To compile with the HPUX C compiler, you must specify get the file 765: `alloca.c' from GNU Emacs. Then, when you run `make', use this 766: argument: 767: 768: make ALLOCA=alloca.o 769: 770: When recompiling GNU CC with itself, do not define `ALLOCA'. 771: Instead, an `-I' option needs to be added to `CFLAGS' as follows: 772: 773: make CC=stage1/gcc CFLAGS="-g -O -Bstage1/ -I../binutils/hp-include" 1.1.1.14 root 774: 775: 776: 1.1.1.15! root 777: File: gcc.info, Node: MIPS Install, Next: Tower Install, Prev: HPUX Install, Up: Installation 1.1.1.14 root 778: 779: Installing GNU CC on MIPS 780: ========================= 781: 782: To avoid errors when linking programs with `-g', create an empty 783: library named `libg.a'. An easy way to do this is: 784: 785: ar rc /usr/local/lib/libg.a 1.1.1.15! root 786: ! 787: ! 788: ! 789: File: gcc.info, Node: Tower Install, Prev: MIPS Install, Up: Installation ! 790: ! 791: Installing GNU CC on an NCR Tower ! 792: ================================= ! 793: ! 794: On an NCR Tower model 4x0 or 6x0, you may have trouble because the ! 795: default maximum virtual address size of a process is just 1 Mb. Most ! 796: often you will find this problem while compiling GNU CC with itself. ! 797: ! 798: The only way to solve the problem is to reconfigure the kernel. Add ! 799: a line such as this to the configuration file: ! 800: ! 801: MAXUMEM = 4096 ! 802: ! 803: and then relink the kernel and reboot the machine.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.