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