![[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.5 root 1: This file documents the installation of the GNU compiler. Copyright 1.1.1.8 ! root 2: (C) 1988, 1989, 1992, 1994, 1995 Free Software Foundation, Inc. You ! 3: may copy, distribute, and modify it freely as long as you preserve this ! 4: copyright notice and permission notice. 1.1 root 5: 6: Installing GNU CC 1.1.1.5 root 7: ***************** 1.1 root 8: 1.1.1.7 root 9: Here is the procedure for installing GNU CC on a Unix system. See 10: *Note VMS Install::, for VMS systems. In this section we assume you 11: compile in the same directory that contains the source files; see *Note 12: Other Dir::, to find out how to compile in a separate directory on Unix 13: systems. 1.1 root 14: 1.1.1.6 root 15: You cannot install GNU C by itself on MSDOS; it will not compile 16: under any MSDOS compiler except itself. You need to get the complete 17: compilation package DJGPP, which includes binaries as well as sources, 18: and includes all the necessary compilation tools and libraries. 19: 1.1 root 20: 1. If you have built GNU CC previously in the same directory for a 1.1.1.2 root 21: different target machine, do `make distclean' to delete all files 1.1.1.4 root 22: that might be invalid. One of the files this deletes is 23: `Makefile'; if `make distclean' complains that `Makefile' does not 24: exist, it probably means that the directory is already suitably 25: clean. 1.1 root 26: 1.1.1.3 root 27: 2. On a System V release 4 system, make sure `/usr/bin' precedes 1.1 root 28: `/usr/ucb' in `PATH'. The `cc' command in `/usr/ucb' uses 29: libraries which have bugs. 30: 1.1.1.7 root 31: 3. Specify the host, build and target machine configurations. You do 32: this by running the file `configure'. 33: 34: The "build" machine is the system which you are using, the "host" 35: machine is the system where you want to run the resulting compiler 36: (normally the build machine), and the "target" machine is the 37: system for which you want the compiler to generate code. 1.1 root 38: 1.1.1.3 root 39: If you are building a compiler to produce code for the machine it 1.1.1.7 root 40: runs on (a native compiler), you normally do not need to specify 41: any operands to `configure'; it will try to guess the type of 42: machine you are on and use that as the build, host and target 43: machines. So you don't need to specify a configuration when 44: building a native compiler unless `configure' cannot figure out 45: what your configuration is or guesses wrong. 46: 47: In those cases, specify the build machine's "configuration name" 48: with the `--build' option; the host and target will default to be 49: the same as the build machine. (If you are building a 50: cross-compiler, see *Note Cross-Compiler::.) 51: 52: Here is an example: 53: 54: ./configure --build=sparc-sun-sunos4.1 1.1.1.6 root 55: 1.1.1.3 root 56: A configuration name may be canonical or it may be more or less 1.1 root 57: abbreviated. 58: 1.1.1.3 root 59: A canonical configuration name has three parts, separated by 1.1.1.5 root 60: dashes. It looks like this: `CPU-COMPANY-SYSTEM'. (The three 61: parts may themselves contain dashes; `configure' can figure out 62: which dashes serve which purpose.) For example, 63: `m68k-sun-sunos4.1' specifies a Sun 3. 1.1 root 64: 1.1.1.3 root 65: You can also replace parts of the configuration by nicknames or 1.1.1.5 root 66: aliases. For example, `sun3' stands for `m68k-sun', so 1.1 root 67: `sun3-sunos4.1' is another way to specify a Sun 3. You can also 1.1.1.2 root 68: use simply `sun3-sunos', since the version of SunOS is assumed by 1.1.1.3 root 69: default to be version 4. `sun3-bsd' also works, since `configure' 70: knows that the only BSD variant on a Sun 3 is SunOS. 71: 72: You can specify a version number after any of the system types, 73: and some of the CPU types. In most cases, the version is 74: irrelevant, and will be ignored. So you might as well specify the 75: version if you know it. 1.1 root 76: 1.1.1.7 root 77: See *Note Configurations::, for a list of supported configuration 78: names and notes on many of the configurations. You should check 1.1.1.8 ! root 79: the notes in that section before proceeding any further with the 1.1.1.7 root 80: installation of GNU CC. 1.1 root 81: 1.1.1.4 root 82: There are four additional options you can specify independently to 1.1.1.3 root 83: describe variant hardware and software configurations. These are 1.1.1.4 root 84: `--with-gnu-as', `--with-gnu-ld', `--with-stabs' and `--nfp'. 1.1.1.3 root 85: 86: `--with-gnu-as' 1.1.1.5 root 87: If you will use GNU CC with the GNU assembler (GAS), you 88: should declare this by using the `--with-gnu-as' option when 89: you run `configure'. 90: 91: Using this option does not install GAS. It only modifies the 92: output of GNU CC to work with GAS. Building and installing 93: GAS is up to you. 94: 1.1.1.6 root 95: Conversely, if you *do not* wish to use GAS and do not specify 96: `--with-gnu-as' when building GNU CC, it is up to you to make 97: sure that GAS is not installed. GNU CC searches for a 98: program named `as' in various directories; if the program it 99: finds is GAS, then it runs GAS. If you are not sure where 100: GNU CC finds the assembler it is using, try specifying `-v' 101: when you run it. 1.1.1.5 root 102: 1.1.1.6 root 103: The systems where it makes a difference whether you use GAS 104: are 105: `hppa1.0-ANY-ANY', `hppa1.1-ANY-ANY', `i386-ANY-sysv', 106: `i386-ANY-isc', 107: `i860-ANY-bsd', `m68k-bull-sysv', `m68k-hp-hpux', 108: `m68k-sony-bsd', 1.1.1.8 ! root 109: `m68k-altos-sysv', `m68000-hp-hpux', `m68000-att-sysv', ! 110: `ANY-lynx-lynxos', and `mips-ANY'). On any other system, ! 111: `--with-gnu-as' has no effect. 1.1.1.6 root 112: 1.1.1.7 root 113: On the systems listed above (except for the HP-PA, for ISC on 114: the 386, and for `mips-sgi-irix5.*'), if you use GAS, you 115: should also use the GNU linker (and specify `--with-gnu-ld'). 1.1.1.3 root 116: 117: `--with-gnu-ld' 118: Specify the option `--with-gnu-ld' if you plan to use the GNU 1.1.1.5 root 119: linker with GNU CC. 120: 121: This option does not cause the GNU linker to be installed; it 122: just modifies the behavior of GNU CC to work with the GNU 123: linker. Specifically, it inhibits the installation of 124: `collect2', a program which otherwise serves as a front-end 125: for the system's linker on most configurations. 1.1.1.3 root 126: 1.1.1.4 root 127: `--with-stabs' 1.1.1.6 root 128: On MIPS based systems and on Alphas, you must specify whether 129: you want GNU CC to create the normal ECOFF debugging format, 130: or to use BSD-style stabs passed through the ECOFF symbol 131: table. The normal ECOFF debug format cannot fully handle 132: languages other than C. BSD stabs format can handle other 133: languages, but it only works with the GNU debugger GDB. 1.1.1.4 root 134: 135: Normally, GNU CC uses the ECOFF debugging format by default; 136: if you prefer BSD stabs, specify `--with-stabs' when you 137: configure GNU CC. 138: 139: No matter which default you choose when you configure GNU CC, 140: the user can use the `-gcoff' and `-gstabs+' options to 141: specify explicitly the debug format for a particular 142: compilation. 143: 1.1.1.6 root 144: `--with-stabs' is meaningful on the ISC system on the 386, 145: also, if `--with-gas' is used. It selects use of stabs 146: debugging information embedded in COFF output. This kind of 147: debugging information supports C++ well; ordinary COFF 148: debugging information does not. 149: 1.1.1.7 root 150: `--with-stabs' is also meaningful on 386 systems running 151: SVR4. It selects use of stabs debugging information embedded 152: in ELF output. The C++ compiler currently (2.6.0) does not 153: support the DWARF debugging information normally used on 386 154: SVR4 platforms; stabs provide a workable alternative. This 155: requires gas and gdb, as the normal SVR4 tools can not 156: generate or interpret stabs. 157: 1.1.1.3 root 158: `--nfp' 159: On certain systems, you must specify whether the machine has 1.1.1.5 root 160: a floating point unit. These systems include 161: `m68k-sun-sunosN' and `m68k-isi-bsd'. On any other system, 162: `--nfp' currently has no effect, though perhaps there are 163: other systems where it could usefully make a difference. 1.1.1.3 root 164: 1.1.1.7 root 165: The `configure' script searches subdirectories of the source 166: directory for other compilers that are to be integrated into GNU 167: CC. The GNU compiler for C++, called G++ is in a subdirectory 168: named `cp'. `configure' inserts rules into `Makefile' to build 169: all of those compilers. 1.1 root 170: 1.1.1.5 root 171: Here we spell out what files will be set up by `configure'. 1.1 root 172: Normally you need not be concerned with these files. 173: 1.1.1.8 ! root 174: * A file named `config.h' is created that contains a `#include' ! 175: of the top-level config file for the machine you will run the ! 176: compiler on (*note The Configuration File: ! 177: (gcc.info)Config.). This file is responsible for defining ! 178: information about the host machine. It includes `tm.h'. 1.1 root 179: 180: The top-level config file is located in the subdirectory 1.1.1.5 root 181: `config'. Its name is always `xm-SOMETHING.h'; usually 1.1 root 182: `xm-MACHINE.h', but there are some exceptions. 183: 184: If your system does not support symbolic links, you might 185: want to set up `config.h' to contain a `#include' command 186: which refers to the appropriate file. 187: 1.1.1.8 ! root 188: * A file named `tconfig.h' is created which includes the ! 189: top-level config file for your target machine. This is used ! 190: for compiling certain programs to run on that machine. 1.1 root 191: 1.1.1.8 ! root 192: * A file named `tm.h' is created which includes the 1.1 root 193: machine-description macro file for your target machine. It 194: should be in the subdirectory `config' and its name is often 195: `MACHINE.h'. 196: 1.1.1.5 root 197: * The command file `configure' also constructs the file 198: `Makefile' by adding some text to the template file 199: `Makefile.in'. The additional text comes from files in the 200: `config' directory, named `t-TARGET' and `x-HOST'. If these 201: files do not exist, it means nothing needs to be added for a 202: given target or host. 203: 204: 4. The standard directory for installing GNU CC is `/usr/local/lib'. 205: If you want to install its files somewhere else, specify 206: `--prefix=DIR' when you run `configure'. Here DIR is a directory 207: name to use instead of `/usr/local' for all purposes with one 208: exception: the directory `/usr/local/include' is searched for 1.1.1.7 root 209: header files no matter where you install the compiler. To override 210: this name, use the `--local-prefix' option below. 1.1.1.5 root 211: 212: 5. Specify `--local-prefix=DIR' if you want the compiler to search 1.1.1.7 root 213: directory `DIR/include' for locally installed header files 214: *instead* of `/usr/local/include'. 1.1 root 215: 1.1.1.7 root 216: You should specify `--local-prefix' *only* if your site has a 217: different convention (not `/usr/local') for where to put 218: site-specific files. 219: 220: *Do not* specify `/usr' as the `--local-prefix'! The directory 221: you use for `--local-prefix' *must not* contain any of the 222: system's standard header files. If it did contain them, certain 223: programs would be miscompiled (including GNU Emacs, on certain 224: targets), because this would override and nullify the header file 225: corrections made by the `fixincludes' script. 1.1.1.6 root 226: 1.1.1.5 root 227: 6. Make sure the Bison parser generator is installed. (This is 1.1.1.3 root 228: unnecessary if the Bison output files `c-parse.c' and `cexp.c' are 229: more recent than `c-parse.y' and `cexp.y' and you do not plan to 230: change the `.y' files.) 1.1 root 231: 1.1.1.3 root 232: Bison versions older than Sept 8, 1988 will produce incorrect 1.1 root 233: output for `c-parse.c'. 234: 1.1.1.6 root 235: 7. If you have chosen a configuration for GNU CC which requires other 236: GNU tools (such as GAS or the GNU linker) instead of the standard 237: system tools, install the required tools in the build directory 238: under the names `as', `ld' or whatever is appropriate. This will 239: enable the compiler to find the proper tools for compilation of 240: the program `enquire'. 241: 242: Alternatively, you can do subsequent compilation using a value of 243: the `PATH' environment variable such that the necessary GNU tools 244: come before the standard system tools. 245: 246: 8. Build the compiler. Just type `make LANGUAGES=c' in the compiler 1.1 root 247: directory. 248: 1.1.1.3 root 249: `LANGUAGES=c' specifies that only the C compiler should be 1.1 root 250: compiled. The makefile normally builds compilers for all the 251: supported languages; currently, C, C++ and Objective C. However, 252: C is the only language that is sure to work when you build with 253: other non-GNU C compilers. In addition, building anything but C 254: at this stage is a waste of time. 255: 1.1.1.3 root 256: In general, you can specify the languages to build by typing the 257: argument `LANGUAGES="LIST"', where LIST is one or more words from 1.1.1.7 root 258: the list `c', `c++', and `objective-c'. If you have any 259: additional GNU compilers as subdirectories of the GNU CC source 260: directory, you may also specify their names in this list. 1.1.1.3 root 261: 262: Ignore any warnings you may see about "statement not reached" in 1.1.1.5 root 263: `insn-emit.c'; they are normal. Also, warnings about "unknown 264: escape sequence" are normal in `genopinit.c' and perhaps some 1.1.1.7 root 265: other files. Likewise, you should ignore warnings about "constant 266: is so large that it is unsigned" in `insn-emit.c' and 1.1.1.8 ! root 267: `insn-recog.c' and a warning about a comparison always being zero ! 268: in `enquire.o'. Any other compilation errors may represent bugs in 1.1.1.5 root 269: the port to your machine or operating system, and should be 270: investigated and reported. 1.1.1.3 root 271: 272: Some commercial compilers fail to compile GNU CC because they have 273: bugs or limitations. For example, the Microsoft compiler is said 274: to run out of macro space. Some Ultrix compilers run out of 1.1 root 275: expression space; then you need to break up the statement where 276: the problem happens. 277: 1.1.1.6 root 278: 9. If you are building a cross-compiler, stop here. *Note 1.1.1.3 root 279: Cross-Compiler::. 1.1 root 280: 1.1.1.6 root 281: 10. Move the first-stage object files and executables into a 1.1 root 282: subdirectory with this command: 283: 284: make stage1 285: 1.1.1.5 root 286: The files are moved into a subdirectory named `stage1'. Once 1.1 root 287: installation is complete, you may wish to delete these files with 288: `rm -r stage1'. 289: 1.1.1.6 root 290: 11. If you have chosen a configuration for GNU CC which requires other 1.1.1.5 root 291: GNU tools (such as GAS or the GNU linker) instead of the standard 292: system tools, install the required tools in the `stage1' 293: subdirectory under the names `as', `ld' or whatever is 294: appropriate. This will enable the stage 1 compiler to find the 295: proper tools in the following stage. 296: 297: Alternatively, you can do subsequent compilation using a value of 298: the `PATH' environment variable such that the necessary GNU tools 299: come before the standard system tools. 300: 1.1.1.6 root 301: 12. Recompile the compiler with itself, with this command: 1.1 root 302: 1.1.1.8 ! root 303: make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2" 1.1 root 304: 1.1.1.3 root 305: This is called making the stage 2 compiler. 1.1 root 306: 1.1.1.3 root 307: The command shown above builds compilers for all the supported 1.1 root 308: languages. If you don't want them all, you can specify the 1.1.1.3 root 309: languages to build by typing the argument `LANGUAGES="LIST"'. LIST 310: should contain one or more words from the list `c', `c++', 311: `objective-c', and `proto'. Separate the words with spaces. 312: `proto' stands for the programs `protoize' and `unprotoize'; they 313: are not a separate language, but you use `LANGUAGES' to enable or 314: disable their installation. 315: 316: If you are going to build the stage 3 compiler, then you might 317: want to build only the C language in stage 2. 318: 319: Once you have built the stage 2 compiler, if you are short of disk 320: space, you can delete the subdirectory `stage1'. 321: 322: On a 68000 or 68020 system lacking floating point hardware, unless 323: you have selected a `tm.h' file that expects by default that there 324: is no such hardware, do this instead: 1.1 root 325: 1.1.1.8 ! root 326: make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2 -msoft-float" 1.1 root 327: 1.1.1.6 root 328: 13. If you wish to test the compiler by compiling it with itself one 1.1.1.5 root 329: more time, install any other necessary GNU tools (such as GAS or 330: the GNU linker) in the `stage2' subdirectory as you did in the 331: `stage1' subdirectory, then do this: 1.1 root 332: 333: make stage2 1.1.1.8 ! root 334: make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2" 1.1 root 335: 336: This is called making the stage 3 compiler. Aside from the `-B' 1.1.1.4 root 337: option, the compiler options should be the same as when you made 338: the stage 2 compiler. But the `LANGUAGES' option need not be the 339: same. The command shown above builds compilers for all the 340: supported languages; if you don't want them all, you can specify 341: the languages to build by typing the argument `LANGUAGES="LIST"', 342: as described above. 1.1 root 343: 1.1.1.7 root 344: If you do not have to install any additional GNU tools, you may 345: use the command 346: 347: make bootstrap LANGUAGES=LANGUAGE-LIST BOOT_CFLAGS=OPTION-LIST 348: 349: instead of making `stage1', `stage2', and performing the two 350: compiler builds. 351: 352: 14. Then compare the latest object files with the stage 2 object 1.1.1.6 root 353: files--they ought to be identical, aside from time stamps (if any). 354: 355: On some systems, meaningful comparison of object files is 356: impossible; they always appear "different." This is currently 1.1.1.8 ! root 357: true on Solaris and some systems that use ELF object file format. ! 358: On some versions of Irix on SGI machines and DEC Unix (OSF/1) on ! 359: Alpha systems, you will not be able to compare the files without ! 360: specifying `-save-temps'; see the description of individual ! 361: systems above to see if you get comparison failures. You may have ! 362: similar problems on other systems. 1.1.1.6 root 363: 364: Use this command to compare the files: 1.1.1.3 root 365: 366: make compare 367: 368: This will mention any object files that differ between stage 2 and 369: stage 3. Any difference, no matter how innocuous, indicates that 370: the stage 2 compiler has compiled GNU CC incorrectly, and is 1.1 root 371: therefore a potentially serious bug which you should investigate 1.1.1.3 root 372: and report. 1.1 root 373: 1.1.1.3 root 374: If your system does not put time stamps in the object files, then 375: this is a faster way to compare them (using the Bourne shell): 1.1 root 376: 377: for file in *.o; do 1.1.1.3 root 378: cmp $file stage2/$file 1.1 root 379: done 380: 1.1.1.3 root 381: If you have built the compiler with the `-mno-mips-tfile' option on 382: MIPS machines, you will not be able to compare the files. 1.1 root 383: 1.1.1.8 ! root 384: 15. Install the compiler driver, the compiler's passes and run-time 1.1.1.5 root 385: support with `make install'. Use the same value for `CC', 386: `CFLAGS' and `LANGUAGES' that you used when compiling the files 387: that are being installed. One reason this is necessary is that 388: some versions of Make have bugs and recompile files gratuitously 389: when you do this step. If you use the same variable values, those 390: files will be recompiled properly. 1.1 root 391: 1.1.1.5 root 392: For example, if you have built the stage 2 compiler, you can use 393: the following command: 1.1 root 394: 1.1.1.5 root 395: make install CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" LANGUAGES="LIST" 1.1 root 396: 1.1.1.3 root 397: This copies the files `cc1', `cpp' and `libgcc.a' to files `cc1', 1.1.1.5 root 398: `cpp' and `libgcc.a' in the directory 1.1.1.2 root 399: `/usr/local/lib/gcc-lib/TARGET/VERSION', which is where the 400: compiler driver program looks for them. Here TARGET is the target 401: machine type specified when you ran `configure', and VERSION is 402: the version number of GNU CC. This naming scheme permits various 1.1 root 403: versions and/or cross-compilers to coexist. 404: 1.1.1.5 root 405: This also copies the driver program `xgcc' into 406: `/usr/local/bin/gcc', so that it appears in typical execution 407: search paths. 408: 409: On some systems, this command causes recompilation of some files. 410: This is usually due to bugs in `make'. You should either ignore 411: this problem, or use GNU Make. 1.1.1.3 root 412: 413: *Warning: there is a bug in `alloca' in the Sun library. To avoid 414: this bug, be sure to install the executables of GNU CC that were 415: compiled by GNU CC. (That is, the executables from stage 2 or 3, 416: not stage 1.) They use `alloca' as a built-in function and never 417: the one in the library.* 1.1.1.2 root 418: 1.1.1.3 root 419: (It is usually better to install GNU CC executables from stage 2 420: or 3, since they usually run faster than the ones compiled with 1.1.1.2 root 421: some other compiler.) 1.1 root 422: 1.1.1.8 ! root 423: 16. If you're going to use C++, it's likely that you need to also 1.1.1.5 root 424: install the libg++ distribution. It should be available from the 425: same place where you got the GNU C distribution. Just as GNU C 1.1.1.4 root 426: does not distribute a C runtime library, it also does not include 427: a C++ run-time library. All I/O functionality, special class 1.1.1.5 root 428: libraries, etc., are available in the libg++ distribution. 1.1 root 429: 1.1.1.7 root 430: Configurations Supported by GNU CC 431: ================================== 432: 433: Here are the possible CPU types: 434: 435: 1750a, a29k, alpha, arm, cN, clipper, dsp16xx, elxsi, h8300, 1.1.1.8 ! root 436: hppa1.0, hppa1.1, i370, i386, i486, i586, i860, i960, m68000, m68k, ! 437: m88k, mips, mipsel, mips64, mips64el, ns32k, powerpc, powerpcle, ! 438: pyramid, romp, rs6000, sh, sparc, sparclite, sparc64, vax, we32k. 1.1.1.7 root 439: 440: Here are the recognized company names. As you can see, customary 441: abbreviations are used rather than the longer official names. 442: 443: acorn, alliant, altos, apollo, att, bull, cbm, convergent, convex, 444: crds, dec, dg, dolphin, elxsi, encore, harris, hitachi, hp, ibm, 445: intergraph, isi, mips, motorola, ncr, next, ns, omron, plexus, 1.1.1.8 ! root 446: sequent, sgi, sony, sun, tti, unicom, wrs. 1.1.1.7 root 447: 448: The company name is meaningful only to disambiguate when the rest of 449: the information supplied is insufficient. You can omit it, writing 450: just `CPU-SYSTEM', if it is not needed. For example, `vax-ultrix4.2' 451: is equivalent to `vax-dec-ultrix4.2'. 452: 453: Here is a list of system types: 454: 1.1.1.8 ! root 455: 386bsd, aix, acis, amigados, aos, aout, bosx, bsd, clix, coff, ! 456: ctix, cxux, dgux, dynix, ebmon, ecoff, elf, esix, freebsd, hms, ! 457: genix, gnu, gnu/linux, hiux, hpux, iris, irix, isc, luna, lynxos, ! 458: mach, minix, msdos, mvs, netbsd, newsos, nindy, ns, osf, osfrose, ! 459: ptx, riscix, riscos, rtu, sco, sim, solaris, sunos, sym, sysv, ! 460: udi, ultrix, unicos, uniplus, unos, vms, vsta, vxworks, winnt, ! 461: xenix. 1.1.1.7 root 462: 463: You can omit the system type; then `configure' guesses the operating 464: system from the CPU and company. 465: 466: You can add a version number to the system type; this may or may not 467: make a difference. For example, you can write `bsd4.3' or `bsd4.4' to 468: distinguish versions of BSD. In practice, the version number is most 469: needed for `sysv3' and `sysv4', which are often treated differently. 470: 471: If you specify an impossible combination such as `i860-dg-vms', then 472: you may get an error message from `configure', or it may ignore part of 473: the information and do the best it can with the rest. `configure' 474: always prints the canonical name for the alternative that it used. GNU 475: CC does not support all possible alternatives. 476: 477: Often a particular model of machine has a name. Many machine names 478: are recognized as aliases for CPU/company combinations. Thus, the 479: machine name `sun3', mentioned above, is an alias for `m68k-sun'. 480: Sometimes we accept a company name as a machine name, when the name is 481: popularly used for a particular machine. Here is a table of the known 482: machine names: 483: 484: 3300, 3b1, 3bN, 7300, altos3068, altos, apollo68, att-7300, 485: balance, convex-cN, crds, decstation-3100, decstation, delta, 486: encore, fx2800, gmicro, hp7NN, hp8NN, hp9k2NN, hp9k3NN, hp9k7NN, 487: hp9k8NN, iris4d, iris, isi68, m3230, magnum, merlin, miniframe, 488: mmax, news-3600, news800, news, next, pbd, pc532, pmax, powerpc, 1.1.1.8 ! root 489: powerpcle, ps2, risc-news, rtpc, sun2, sun386i, sun386, sun3, ! 490: sun4, symmetry, tower-32, tower. 1.1.1.7 root 491: 492: Remember that a machine name specifies both the cpu type and the company 493: name. If you want to install your own homemade configuration files, 494: you can use `local' as the company name to access them. If you use 495: configuration `CPU-local', the configuration name without the cpu prefix 496: is used to form the configuration file names. 497: 498: Thus, if you specify `m68k-local', configuration uses files 499: `m68k.md', `local.h', `m68k.c', `xm-local.h', `t-local', and `x-local', 500: all in the directory `config/m68k'. 501: 502: Here is a list of configurations that have special treatment or 503: special things you must know: 504: 505: `1750a-*-*' 506: MIL-STD-1750A processors. 507: 508: Starting with GCC 2.6.1, the MIL-STD-1750A cross configuration no 509: longer supports the Tektronix Assembler, but instead produces 510: output for `as1750', an assembler/linker available under the GNU 1.1.1.8 ! root 511: Public License for the 1750A. Contact *[email protected]* 1.1.1.7 root 512: for more details on obtaining `as1750'. A similarly licensed 513: simulator for the 1750A is available from same address. 514: 515: You should ignore a fatal error during the building of libgcc 516: (libgcc is not yet implemented for the 1750A.) 517: 518: The `as1750' assembler requires the file `ms1750.inc', which is 519: found in the directory `config/1750a'. 520: 521: GNU CC produced the same sections as the Fairchild F9450 C 522: Compiler, namely: 523: 1.1.1.8 ! root 524: `Normal' 1.1.1.7 root 525: The program code section. 526: 1.1.1.8 ! root 527: `Static' 1.1.1.7 root 528: The read/write (RAM) data section. 529: 1.1.1.8 ! root 530: `Konst' 1.1.1.7 root 531: The read-only (ROM) constants section. 532: 1.1.1.8 ! root 533: `Init' 1.1.1.7 root 534: Initialization section (code to copy KREL to SREL). 535: 536: The smallest addressable unit is 16 bits (BITS_PER_UNIT is 16). 537: This means that type `char' is represented with a 16-bit word per 538: character. The 1750A's "Load/Store Upper/Lower Byte" instructions 539: are not used by GNU CC. 540: 541: `alpha-*-osf1' 542: Systems using processors that implement the DEC Alpha architecture 1.1.1.8 ! root 543: and are running the DEC Unix (OSF/1) operating system, for example ! 544: the DEC Alpha AXP systems. (VMS on the Alpha is not currently ! 545: supported by GNU CC.) 1.1.1.7 root 546: 547: GNU CC writes a `.verstamp' directive to the assembler output file 548: unless it is built as a cross-compiler. It gets the version to 549: use from the system header file `/usr/include/stamp.h'. If you 1.1.1.8 ! root 550: install a new version of DEC Unix, you should rebuild GCC to pick ! 551: up the new version stamp. 1.1.1.7 root 552: 553: Note that since the Alpha is a 64-bit architecture, 554: cross-compilers from 32-bit machines will not generate code as 555: efficient as that generated when the compiler is running on a 556: 64-bit machine because many optimizations that depend on being 557: able to represent a word on the target in an integral value on the 558: host cannot be performed. Building cross-compilers on the Alpha 559: for 32-bit machines has only been tested in a few cases and may 560: not work properly. 561: 1.1.1.8 ! root 562: `make compare' may fail on old versions of DEC Unix unless you add 1.1.1.7 root 563: `-save-temps' to `CFLAGS'. On these systems, the name of the 564: assembler input file is stored in the object file, and that makes 565: comparison fail if it differs between the `stage1' and `stage2' 566: compilations. The option `-save-temps' forces a fixed name to be 567: used for the assembler input file, instead of a randomly chosen 568: name in `/tmp'. Do not add `-save-temps' unless the comparisons 569: fail without that option. If you add `-save-temps', you will have 570: to manually delete the `.i' and `.s' files after each series of 571: compilations. 572: 573: GNU CC now supports both the native (ECOFF) debugging format used 574: by DBX and GDB and an encapsulated STABS format for use only with 575: GDB. See the discussion of the `--with-stabs' option of 576: `configure' above for more information on these formats and how to 577: select them. 578: 579: There is a bug in DEC's assembler that produces incorrect line 580: numbers for ECOFF format when the `.align' directive is used. To 581: work around this problem, GNU CC will not emit such alignment 582: directives while writing ECOFF format debugging information even 583: if optimization is being performed. Unfortunately, this has the 584: very undesirable side-effect that code addresses when `-O' is 585: specified are different depending on whether or not `-g' is also 586: specified. 587: 588: To avoid this behavior, specify `-gstabs+' and use GDB instead of 589: DBX. DEC is now aware of this problem with the assembler and 590: hopes to provide a fix shortly. 591: 592: `arm' 593: Advanced RISC Machines ARM-family processors. These are often 594: used in embedded applications. There are no standard Unix 595: configurations. This configuration corresponds to the basic 596: instruction sequences and will produce a.out format object modules. 597: 598: You may need to make a variant of the file `arm.h' for your 599: particular configuration. 600: 601: `arm-*-riscix' 602: The ARM2 or ARM3 processor running RISC iX, Acorn's port of BSD 603: Unix. If you are running a version of RISC iX prior to 1.2 then 604: you must specify the version number during configuration. Note 605: that the assembler shipped with RISC iX does not support stabs 606: debugging information; a new version of the assembler, with stabs 607: support included, is now available from Acorn. 608: 609: `a29k' 610: AMD Am29k-family processors. These are normally used in embedded 611: applications. There are no standard Unix configurations. This 612: configuration corresponds to AMD's standard calling sequence and 613: binary interface and is compatible with other 29k tools. 614: 615: You may need to make a variant of the file `a29k.h' for your 616: particular configuration. 617: 618: `a29k-*-bsd' 619: AMD Am29050 used in a system running a variant of BSD Unix. 620: 621: `decstation-*' 622: DECstations can support three different personalities: Ultrix, DEC 623: OSF/1, and OSF/rose. To configure GCC for these platforms use the 624: following configurations: 625: 626: `decstation-ultrix' 627: Ultrix configuration. 628: 629: `decstation-osf1' 630: Dec's version of OSF/1. 631: 632: `decstation-osfrose' 633: Open Software Foundation reference port of OSF/1 which uses 634: the OSF/rose object file format instead of ECOFF. Normally, 635: you would not select this configuration. 636: 637: The MIPS C compiler needs to be told to increase its table size 638: for switch statements with the `-Wf,-XNg1500' option in order to 639: compile `cp/parse.c'. If you use the `-O2' optimization option, 640: you also need to use `-Olimit 3000'. Both of these options are 641: automatically generated in the `Makefile' that the shell script 642: `configure' builds. If you override the `CC' make variable and 643: use the MIPS compilers, you may need to add `-Wf,-XNg1500 -Olimit 644: 3000'. 645: 646: `elxsi-elxsi-bsd' 647: The Elxsi's C compiler has known limitations that prevent it from 648: compiling GNU C. Please contact `[email protected]' for more details. 649: 650: `dsp16xx' 651: A port to the AT&T DSP1610 family of processors. 652: 653: `h8300-*-*' 654: The calling convention and structure layout has changed in release 655: 2.6. All code must be recompiled. The calling convention now 656: passes the first three arguments in function calls in registers. 657: Structures are no longer a multiple of 2 bytes. 658: 659: `hppa*-*-*' 660: There are two variants of this CPU, called 1.0 and 1.1, which have 661: different machine descriptions. You must use the right one for 662: your machine. All 7NN machines and 8N7 machines use 1.1, while 663: all other 8NN machines use 1.0. 664: 665: The easiest way to handle this problem is to use `configure hpNNN' 666: or `configure hpNNN-hpux', where NNN is the model number of the 667: machine. Then `configure' will figure out if the machine is a 1.0 668: or 1.1. Use `uname -a' to find out the model number of your 669: machine. 670: 671: `-g' does not work on HP-UX, since that system uses a peculiar 672: debugging format which GNU CC does not know about. However, `-g' 673: will work if you also use GAS and GDB in conjunction with GCC. We 674: highly recommend using GAS for all HP-PA configurations. 675: 676: You should be using GAS-2.3 (or later) along with GDB-4.12 (or 677: later). These can be retrieved from all the traditional GNU ftp 678: archive sites. 679: 680: Build GAS and install the resulting binary as: 681: 682: /usr/local/lib/gcc-lib/CONFIGURATION/GCCVERSION/as 683: 684: where CONFIGURATION is the configuration name (perhaps 685: `hpNNN-hpux') and GCCVERSION is the GNU CC version number. Do 686: this *before* starting the build process, otherwise you will get 687: errors from the HPUX assembler while building `libgcc2.a'. The 688: command 689: 690: make install-dir 691: 692: will create the necessary directory hierarchy so you can install 693: GAS before building GCC. 694: 695: To enable debugging, configure GNU CC with the `--with-gnu-as' 696: option before building. 697: 698: It has been reported that GNU CC produces invalid assembly code for 699: 1.1 machines running HP-UX 8.02 when using the HP assembler. 700: Typically the errors look like this: 701: as: bug.s @line#15 [err#1060] 702: Argument 0 or 2 in FARG upper 703: - lookahead = ARGW1=FR,RTNVAL=GR 704: as: foo.s @line#28 [err#1060] 705: Argument 0 or 2 in FARG upper 706: - lookahead = ARGW1=FR 707: 708: You can check the version of HP-UX you are running by executing 709: the command `uname -r'. If you are indeed running HP-UX 8.02 on 710: a PA and using the HP assembler then configure GCC with 711: "hpNNN-hpux8.02". 712: 713: `i370-*-*' 714: This port is very preliminary and has many known bugs. We hope to 715: have a higher-quality port for this machine soon. 716: 1.1.1.8 ! root 717: `i386-*-linuxoldld' ! 718: Use this configuration to generate a.out binaries on Linux if you ! 719: do not have gas/binutils version 2.5.2 or later installed. This is ! 720: an obsolete configuration. ! 721: ! 722: `i386-*-linuxaout' ! 723: Use this configuration to generate a.out binaries on Linux. This ! 724: configuration is being superseded. You must use gas/binutils ! 725: version 2.5.2 or later. ! 726: ! 727: `i386-*-linux' ! 728: Use this configuration to generate ELF binaries on Linux. You must ! 729: use gas/binutils version 2.5.2 or later. 1.1.1.7 root 730: 731: `i386-*-sco' 732: Compilation with RCC is recommended. Also, it may be a good idea 733: to link with GNU malloc instead of the malloc that comes with the 734: system. 735: 1.1.1.8 ! root 736: `i386-*-sco3.2v4' 1.1.1.7 root 737: Use this configuration for SCO release 3.2 version 4. 738: 739: `i386-*-isc' 740: It may be a good idea to link with GNU malloc instead of the 741: malloc that comes with the system. 742: 743: In ISC version 4.1, `sed' core dumps when building `deduced.h'. 744: Use the version of `sed' from version 4.0. 745: 746: `i386-*-esix' 747: It may be good idea to link with GNU malloc instead of the malloc 748: that comes with the system. 749: 750: `i386-ibm-aix' 751: You need to use GAS version 2.1 or later, and and LD from GNU 752: binutils version 2.2 or later. 753: 754: `i386-sequent-bsd' 755: Go to the Berkeley universe before compiling. In addition, you 756: probably need to create a file named `string.h' containing just 757: one line: `#include <strings.h>'. 758: 759: `i386-sequent-ptx1*' 760: Sequent DYNIX/ptx 1.x. 761: 762: `i386-sequent-ptx2*' 763: Sequent DYNIX/ptx 2.x. 764: 765: `i386-sun-sunos4' 766: You may find that you need another version of GNU CC to begin 767: bootstrapping with, since the current version when built with the 768: system's own compiler seems to get an infinite loop compiling part 769: of `libgcc2.c'. GNU CC version 2 compiled with GNU CC (any 770: version) seems not to have this problem. 771: 772: See *Note Sun Install::, for information on installing GNU CC on 773: Sun systems. 774: 1.1.1.8 ! root 775: `i[345]86-*-winnt3.5' ! 776: This version requires a GAS that has not let been released. Until ! 777: it is, you can get a prebuilt binary version via anonymous ftp from ! 778: `cs.washington.edu:pub/gnat' or `cs.nyu.edu:pub/gnat'. You must ! 779: also use the Microsoft header files from the Windows NT 3.5 SDK. ! 780: Find these on the CDROM in the `/mstools/h' directory dated ! 781: 9/4/94. You must use a fixed version of Microsoft linker made ! 782: especially for NT 3.5, which is also is available on the NT 3.5 ! 783: SDK CDROM. If you do not have this linker, can you also use the ! 784: linker from Visual C/C++ 1.0 or 2.0. ! 785: ! 786: Installing GNU CC for NT builds a wrapper linker, called `ld.exe', ! 787: which mimics the behaviour of Unix `ld' in the specification of ! 788: libraries (`-L' and `-l'). `ld.exe' looks for both Unix and ! 789: Microsoft named libraries. For example, if you specify `-lfoo', ! 790: `ld.exe' will look first for `libfoo.a' and then for `foo.lib'. ! 791: ! 792: You may install GNU CC for Windows NT in one of two ways, ! 793: depending on whether or not you have a Unix-like shell and various ! 794: Unix-like utilities. ! 795: ! 796: 1. If you do not have a Unix-like shell and few Unix-like ! 797: utilities, you will use a DOS style batch script called ! 798: `configure.bat'. Invoke it as `configure winnt' from an ! 799: MSDOS console window or from the program manager dialog box. ! 800: `configure.bat' assumes you have already installed and have ! 801: in your path a Unix-like `sed' program which is used to ! 802: create a working `Makefile' from `Makefile.in'. ! 803: ! 804: `Makefile' uses the Microsoft Nmake program maintenance ! 805: utility and the Visual C/C++ V8.00 compiler to build GNU CC. ! 806: You need only have the utilities `sed' and `touch' to use ! 807: this installation method, which only automatically builds the ! 808: compiler itself. You must then examine what `fixinc.winnt' ! 809: does, edit the header files by hand and build `libgcc.a' ! 810: manually. ! 811: ! 812: 2. The second type of installation assumes you are running a ! 813: Unix-like shell, have a complete suite of Unix-like utilities ! 814: in your path, and have a previous version of GNU CC already ! 815: installed, either through building it via the above ! 816: installation method or acquiring a pre-built binary. In this ! 817: case, use the `configure' script in the normal fashion. ! 818: 1.1.1.7 root 819: `i860-intel-osf1' 820: This is the Paragon. If you have version 1.0 of the operating 821: system, you need to take special steps to build GNU CC due to 822: peculiarities of the system. Newer system versions have no 823: problem. See the section `Installation Problems' in the GNU CC 824: Manual. 825: 1.1.1.8 ! root 826: `*-lynx-lynxos' ! 827: LynxOS 2.2 and earlier comes with GNU CC 1.x already installed as ! 828: `/bin/gcc'. You should compile with this instead of `/bin/cc'. ! 829: You can tell GNU CC to use the GNU assembler and linker, by ! 830: specifying `--with-gnu-as --with-gnu-ld' when configuring. These ! 831: will produce COFF format object files and executables; otherwise ! 832: GNU CC will use the installed tools, which produce a.out format ! 833: executables. ! 834: 1.1.1.7 root 835: `m68000-hp-bsd' 836: HP 9000 series 200 running BSD. Note that the C compiler that 837: comes with this system cannot compile GNU CC; contact 838: `[email protected]' to get binaries of GNU CC for bootstrapping. 839: 840: `m68k-altos' 841: Altos 3068. You must use the GNU assembler, linker and debugger. 842: Also, you must fix a kernel bug. Details in the file 843: `README.ALTOS'. 844: 845: `m68k-att-sysv' 846: AT&T 3b1, a.k.a. 7300 PC. Special procedures are needed to 847: compile GNU CC with this machine's standard C compiler, due to 848: bugs in that compiler. You can bootstrap it more easily with 849: previous versions of GNU CC if you have them. 850: 851: Installing GNU CC on the 3b1 is difficult if you do not already 852: have GNU CC running, due to bugs in the installed C compiler. 853: However, the following procedure might work. We are unable to 854: test it. 855: 856: 1. Comment out the `#include "config.h"' line on line 37 of 857: `cccp.c' and do `make cpp'. This makes a preliminary version 858: of GNU cpp. 859: 860: 2. Save the old `/lib/cpp' and copy the preliminary GNU cpp to 861: that file name. 862: 863: 3. Undo your change in `cccp.c', or reinstall the original 864: version, and do `make cpp' again. 865: 866: 4. Copy this final version of GNU cpp into `/lib/cpp'. 867: 868: 5. Replace every occurrence of `obstack_free' in the file 869: `tree.c' with `_obstack_free'. 870: 871: 6. Run `make' to get the first-stage GNU CC. 872: 873: 7. Reinstall the original version of `/lib/cpp'. 874: 875: 8. Now you can compile GNU CC with itself and install it in the 876: normal fashion. 877: 878: `m68k-bull-sysv' 879: Bull DPX/2 series 200 and 300 with BOS-2.00.45 up to BOS-2.01. GNU 880: CC works either with native assembler or GNU assembler. You can use 881: GNU assembler with native coff generation by providing 882: `--with-gnu-as' to the configure script or use GNU assembler with 883: dbx-in-coff encapsulation by providing `--with-gnu-as --stabs'. 884: For any problem with native assembler or for availability of the 885: DPX/2 port of GAS, contact `[email protected]'. 886: 887: `m68k-crds-unox' 888: Use `configure unos' for building on Unos. 889: 890: The Unos assembler is named `casm' instead of `as'. For some 891: strange reason linking `/bin/as' to `/bin/casm' changes the 892: behavior, and does not work. So, when installing GNU CC, you 893: should install the following script as `as' in the subdirectory 894: where the passes of GCC are installed: 895: 896: #!/bin/sh 897: casm $* 898: 899: The default Unos library is named `libunos.a' instead of `libc.a'. 900: To allow GNU CC to function, either change all references to 901: `-lc' in `gcc.c' to `-lunos' or link `/lib/libc.a' to 902: `/lib/libunos.a'. 903: 904: When compiling GNU CC with the standard compiler, to overcome bugs 905: in the support of `alloca', do not use `-O' when making stage 2. 906: Then use the stage 2 compiler with `-O' to make the stage 3 907: compiler. This compiler will have the same characteristics as the 908: usual stage 2 compiler on other systems. Use it to make a stage 4 909: compiler and compare that with stage 3 to verify proper 910: compilation. 911: 912: (Perhaps simply defining `ALLOCA' in `x-crds' as described in the 913: comments there will make the above paragraph superfluous. Please 914: inform us of whether this works.) 915: 916: Unos uses memory segmentation instead of demand paging, so you 917: will need a lot of memory. 5 Mb is barely enough if no other 918: tasks are running. If linking `cc1' fails, try putting the object 919: files into a library and linking from that library. 920: 921: `m68k-hp-hpux' 922: HP 9000 series 300 or 400 running HP-UX. HP-UX version 8.0 has a 923: bug in the assembler that prevents compilation of GNU CC. To fix 924: it, get patch PHCO_4484 from HP. 925: 926: In addition, if you wish to use gas `--with-gnu-as' you must use 927: gas version 2.1 or later, and you must use the GNU linker version 928: 2.1 or later. Earlier versions of gas relied upon a program which 929: converted the gas output into the native HP/UX format, but that 930: program has not been kept up to date. gdb does not understand 931: that native HP/UX format, so you must use gas if you wish to use 932: gdb. 933: 934: `m68k-sun' 935: Sun 3. We do not provide a configuration file to use the Sun FPA 936: by default, because programs that establish signal handlers for 937: floating point traps inherently cannot work with the FPA. 938: 939: See *Note Sun Install::, for information on installing GNU CC on 940: Sun systems. 941: 942: `m88k-*-svr3' 943: Motorola m88k running the AT&T/Unisoft/Motorola V.3 reference port. 944: These systems tend to use the Green Hills C, revision 1.8.5, as the 945: standard C compiler. There are apparently bugs in this compiler 946: that result in object files differences between stage 2 and stage 947: 3. If this happens, make the stage 4 compiler and compare it to 948: the stage 3 compiler. If the stage 3 and stage 4 object files are 949: identical, this suggests you encountered a problem with the 950: standard C compiler; the stage 3 and 4 compilers may be usable. 951: 952: It is best, however, to use an older version of GNU CC for 953: bootstrapping if you have one. 954: 955: `m88k-*-dgux' 956: Motorola m88k running DG/UX. To build 88open BCS native or cross 957: compilers on DG/UX, specify the configuration name as 958: `m88k-*-dguxbcs' and build in the 88open BCS software development 959: environment. To build ELF native or cross compilers on DG/UX, 960: specify `m88k-*-dgux' and build in the DG/UX ELF development 961: environment. You set the software development environment by 962: issuing `sde-target' command and specifying either `m88kbcs' or 963: `m88kdguxelf' as the operand. 964: 965: If you do not specify a configuration name, `configure' guesses the 966: configuration based on the current software development 967: environment. 968: 969: `m88k-tektronix-sysv3' 970: Tektronix XD88 running UTekV 3.2e. Do not turn on optimization 971: while building stage1 if you bootstrap with the buggy Green Hills 972: compiler. Also, The bundled LAI System V NFS is buggy so if you 973: build in an NFS mounted directory, start from a fresh reboot, or 974: avoid NFS all together. Otherwise you may have trouble getting 975: clean comparisons between stages. 976: 977: `mips-mips-bsd' 978: MIPS machines running the MIPS operating system in BSD mode. It's 979: possible that some old versions of the system lack the functions 980: `memcpy', `memcmp', and `memset'. If your system lacks these, you 981: must remove or undo the definition of `TARGET_MEM_FUNCTIONS' in 982: `mips-bsd.h'. 983: 984: The MIPS C compiler needs to be told to increase its table size 985: for switch statements with the `-Wf,-XNg1500' option in order to 986: compile `cp/parse.c'. If you use the `-O2' optimization option, 987: you also need to use `-Olimit 3000'. Both of these options are 988: automatically generated in the `Makefile' that the shell script 989: `configure' builds. If you override the `CC' make variable and 990: use the MIPS compilers, you may need to add `-Wf,-XNg1500 -Olimit 991: 3000'. 992: 993: `mips-mips-riscos*' 994: The MIPS C compiler needs to be told to increase its table size 995: for switch statements with the `-Wf,-XNg1500' option in order to 996: compile `cp/parse.c'. If you use the `-O2' optimization option, 997: you also need to use `-Olimit 3000'. Both of these options are 998: automatically generated in the `Makefile' that the shell script 999: `configure' builds. If you override the `CC' make variable and 1000: use the MIPS compilers, you may need to add `-Wf,-XNg1500 -Olimit 1001: 3000'. 1002: 1003: MIPS computers running RISC-OS can support four different 1004: personalities: default, BSD 4.3, System V.3, and System V.4 (older 1005: versions of RISC-OS don't support V.4). To configure GCC for 1006: these platforms use the following configurations: 1007: 1008: `mips-mips-riscos`rev'' 1009: Default configuration for RISC-OS, revision `rev'. 1010: 1011: `mips-mips-riscos`rev'bsd' 1012: BSD 4.3 configuration for RISC-OS, revision `rev'. 1013: 1014: `mips-mips-riscos`rev'sysv4' 1015: System V.4 configuration for RISC-OS, revision `rev'. 1016: 1017: `mips-mips-riscos`rev'sysv' 1018: System V.3 configuration for RISC-OS, revision `rev'. 1019: 1020: The revision `rev' mentioned above is the revision of RISC-OS to 1021: use. You must reconfigure GCC when going from a RISC-OS revision 1022: 4 to RISC-OS revision 5. This has the effect of avoiding a linker 1023: bug. 1024: 1025: `mips-sgi-*' 1026: In order to compile GCC on an SGI running IRIX 4, the "c.hdr.lib" 1027: option must be installed from the CD-ROM supplied from Silicon 1028: Graphics. This is found on the 2nd CD in release 4.0.1. 1029: 1.1.1.8 ! root 1030: In order to compile GCC on an SGI running IRIX 5, the ! 1031: "compiler_dev.hdr" subsystem must be installed from the IDO CD-ROM ! 1032: supplied by Silicon Graphics. ! 1033: 1.1.1.7 root 1034: `make compare' may fail on version 5 of IRIX unless you add 1035: `-save-temps' to `CFLAGS'. On these systems, the name of the 1036: assembler input file is stored in the object file, and that makes 1037: comparison fail if it differs between the `stage1' and `stage2' 1038: compilations. The option `-save-temps' forces a fixed name to be 1039: used for the assembler input file, instead of a randomly chosen 1040: name in `/tmp'. Do not add `-save-temps' unless the comparisons 1041: fail without that option. If you do you `-save-temps', you will 1042: have to manually delete the `.i' and `.s' files after each series 1043: of compilations. 1044: 1045: The MIPS C compiler needs to be told to increase its table size 1046: for switch statements with the `-Wf,-XNg1500' option in order to 1047: compile `cp/parse.c'. If you use the `-O2' optimization option, 1048: you also need to use `-Olimit 3000'. Both of these options are 1049: automatically generated in the `Makefile' that the shell script 1050: `configure' builds. If you override the `CC' make variable and 1051: use the MIPS compilers, you may need to add `-Wf,-XNg1500 -Olimit 1052: 3000'. 1053: 1054: On Irix version 4.0.5F, and perhaps on some other versions as well, 1055: there is an assembler bug that reorders instructions incorrectly. 1056: To work around it, specify the target configuration 1057: `mips-sgi-irix4loser'. This configuration inhibits assembler 1058: optimization. 1059: 1060: In a compiler configured with target `mips-sgi-irix4', you can turn 1061: off assembler optimization by using the `-noasmopt' option. This 1062: compiler option passes the option `-O0' to the assembler, to 1063: inhibit reordering. 1064: 1065: The `-noasmopt' option can be useful for testing whether a problem 1066: is due to erroneous assembler reordering. Even if a problem does 1067: not go away with `-noasmopt', it may still be due to assembler 1068: reordering--perhaps GNU CC itself was miscompiled as a result. 1069: 1070: To enable debugging under Irix 5, you must use GNU as 2.5 or later, 1.1.1.8 ! root 1071: and use the `--with-gnu-as' configure option when configuring gcc. 1.1.1.7 root 1072: GNU as is distributed as part of the binutils package. 1073: 1074: `mips-sony-sysv' 1075: Sony MIPS NEWS. This works in NEWSOS 5.0.1, but not in 5.0.2 1076: (which uses ELF instead of COFF). Support for 5.0.2 will probably 1077: be provided soon by volunteers. In particular, the linker does 1078: not like the code generated by GCC when shared libraries are 1079: linked in. 1080: 1081: `ns32k-encore' 1082: Encore ns32000 system. Encore systems are supported only under 1083: BSD. 1084: 1085: `ns32k-*-genix' 1086: National Semiconductor ns32000 system. Genix has bugs in `alloca' 1087: and `malloc'; you must get the compiled versions of these from GNU 1088: Emacs. 1089: 1090: `ns32k-sequent' 1091: Go to the Berkeley universe before compiling. In addition, you 1092: probably need to create a file named `string.h' containing just 1093: one line: `#include <strings.h>'. 1094: 1095: `ns32k-utek' 1096: UTEK ns32000 system ("merlin"). The C compiler that comes with 1097: this system cannot compile GNU CC; contact `tektronix!reed!mason' 1098: to get binaries of GNU CC for bootstrapping. 1099: 1100: `romp-*-aos' 1101: `romp-*-mach' 1102: The only operating systems supported for the IBM RT PC are AOS and 1103: MACH. GNU CC does not support AIX running on the RT. We 1104: recommend you compile GNU CC with an earlier version of itself; if 1105: you compile GNU CC with `hc', the Metaware compiler, it will work, 1106: but you will get mismatches between the stage 2 and stage 3 1107: compilers in various files. These errors are minor differences in 1108: some floating-point constants and can be safely ignored; the stage 1109: 3 compiler is correct. 1110: 1111: `rs6000-*-aix' 1112: `powerpc-*-aix' 1113: Various early versions of each release of the IBM XLC compiler 1114: will not bootstrap GNU CC. Symptoms include differences between 1115: the stage2 and stage3 object files, and errors when compiling 1116: `libgcc.a' or `enquire'. Known problematic releases include: 1117: xlc-1.2.1.8, xlc-1.3.0.0 (distributed with AIX 3.2.5), and 1118: xlc-1.3.0.19. Both xlc-1.2.1.28 and xlc-1.3.0.24 (PTF 432238) are 1119: known to produce working versions of GNU CC, but most other recent 1120: releases correctly bootstrap GNU CC. Also, releases of AIX prior 1121: to AIX 3.2.4 include a version of the IBM assembler which does not 1122: accept debugging directives: assembler updates are available as 1.1.1.8 ! root 1123: PTFs. Also, if you are using AIX 3.2.5 or greater and the GNU ! 1124: assembler, you must have a version modified after October 16th, ! 1125: 1995 in order for the GNU C compiler to build. See the file ! 1126: `README.RS6000' for more details on of these problems. 1.1.1.7 root 1127: 1.1.1.8 ! root 1128: GNU CC does not yet support the 64-bit PowerPC instructions. 1.1.1.7 root 1129: 1.1.1.8 ! root 1130: Objective C does not work on this architecture because it makes ! 1131: assumptions that are incompatible with the calling conventions. 1.1.1.7 root 1132: 1133: AIX on the RS/6000 provides support (NLS) for environments outside 1134: of the United States. Compilers and assemblers use NLS to support 1135: locale-specific representations of various objects including 1136: floating-point numbers ("." vs "," for separating decimal 1137: fractions). There have been problems reported where the library 1138: linked with GNU CC does not produce the same floating-point 1139: formats that the assembler accepts. If you have this problem, set 1140: the LANG environment variable to "C" or "En_US". 1141: 1.1.1.8 ! root 1142: Due to changes in the way that GNU CC invokes the binder (linker) ! 1143: for AIX 4.1, you may now receive warnings of duplicate symbols ! 1144: from the link step that were not reported before. The assembly ! 1145: files generated by GNU CC for AIX have always included multiple ! 1146: symbol definitions for certain global variable and function ! 1147: declarations in the original program. The warnings should not ! 1148: prevent the linker from producing a correct library or runnable ! 1149: executable. ! 1150: ! 1151: `powerpc-*-elf' ! 1152: `powerpc-*-sysv4' ! 1153: PowerPC system in big endian mode, running System V.4. ! 1154: ! 1155: This configuration is currently under development. ! 1156: ! 1157: `powerpc-*-eabiaix' ! 1158: Embedded PowerPC system in big endian mode with -mcall-aix ! 1159: selected as the default. This system is currently under ! 1160: development. ! 1161: ! 1162: `powerpc-*-eabisim' ! 1163: Embedded PowerPC system in big endian mode for use in running ! 1164: under the PSIM simulator. This system is currently under ! 1165: development. ! 1166: ! 1167: `powerpc-*-eabi' ! 1168: Embedded PowerPC system in big endian mode. ! 1169: ! 1170: This configuration is currently under development. ! 1171: ! 1172: `powerpcle-*-elf' ! 1173: `powerpcle-*-sysv4' ! 1174: PowerPC system in little endian mode, running System V.4. ! 1175: ! 1176: This configuration is currently under development. ! 1177: ! 1178: `powerpcle-*-sysv4' ! 1179: Embedded PowerPC system in little endian mode. ! 1180: ! 1181: This system is currently under development. ! 1182: ! 1183: `powerpcle-*-eabisim' ! 1184: Embedded PowerPC system in little endian mode for use in running ! 1185: under the PSIM simulator. ! 1186: ! 1187: This system is currently under development. ! 1188: ! 1189: `powerpcle-*-eabi' ! 1190: Embedded PowerPC system in little endian mode. ! 1191: ! 1192: This configuration is currently under development. ! 1193: 1.1.1.7 root 1194: `vax-dec-ultrix' 1195: Don't try compiling with Vax C (`vcc'). It produces incorrect code 1196: in some cases (for example, when `alloca' is used). 1197: 1198: Meanwhile, compiling `cp/parse.c' with pcc does not work because of 1199: an internal table size limitation in that compiler. To avoid this 1200: problem, compile just the GNU C compiler first, and use it to 1201: recompile building all the languages that you want to run. 1202: 1203: `sparc-sun-*' 1204: See *Note Sun Install::, for information on installing GNU CC on 1205: Sun systems. 1206: 1207: `vax-dec-vms' 1208: See *Note VMS Install::, for details on how to install GNU CC on 1209: VMS. 1210: 1211: `we32k-*-*' 1212: These computers are also known as the 3b2, 3b5, 3b20 and other 1213: similar names. (However, the 3b1 is actually a 68000; see *Note 1214: Configurations::.) 1215: 1216: Don't use `-g' when compiling with the system's compiler. The 1217: system's linker seems to be unable to handle such a large program 1218: with debugging information. 1219: 1220: The system's compiler runs out of capacity when compiling `stmt.c' 1221: in GNU CC. You can work around this by building `cpp' in GNU CC 1222: first, then use that instead of the system's preprocessor with the 1223: system's C compiler to compile `stmt.c'. Here is how: 1224: 1225: mv /lib/cpp /lib/cpp.att 1226: cp cpp /lib/cpp.gnu 1227: echo '/lib/cpp.gnu -traditional ${1+"$@"}' > /lib/cpp 1228: chmod +x /lib/cpp 1229: 1230: The system's compiler produces bad code for some of the GNU CC 1231: optimization files. So you must build the stage 2 compiler without 1232: optimization. Then build a stage 3 compiler with optimization. 1233: That executable should work. Here are the necessary commands: 1234: 1235: make LANGUAGES=c CC=stage1/xgcc CFLAGS="-Bstage1/ -g" 1236: make stage2 1237: make CC=stage2/xgcc CFLAGS="-Bstage2/ -g -O" 1238: 1239: You may need to raise the ULIMIT setting to build a C++ compiler, 1240: as the file `cc1plus' is larger than one megabyte. 1241: 1.1 root 1242: Compilation in a Separate Directory 1.1.1.5 root 1243: =================================== 1.1 root 1244: 1245: If you wish to build the object files and executables in a directory 1246: other than the one containing the source files, here is what you must 1247: do differently: 1248: 1249: 1. Make sure you have a version of Make that supports the `VPATH' 1250: feature. (GNU Make supports it, as do Make versions on most BSD 1251: systems.) 1252: 1.1.1.3 root 1253: 2. If you have ever run `configure' in the source directory, you must 1254: undo the configuration. Do this by running: 1.1.1.2 root 1255: 1.1.1.3 root 1256: make distclean 1.1.1.2 root 1257: 1258: 3. Go to the directory in which you want to build the compiler before 1259: running `configure': 1.1 root 1260: 1261: mkdir gcc-sun3 1262: cd gcc-sun3 1263: 1.1.1.3 root 1264: On systems that do not support symbolic links, this directory must 1265: be on the same file system as the source code directory. 1.1 root 1266: 1.1.1.2 root 1267: 4. Specify where to find `configure' when you run it: 1.1 root 1268: 1.1.1.3 root 1269: ../gcc/configure ... 1.1 root 1270: 1.1.1.3 root 1271: This also tells `configure' where to find the compiler sources; 1272: `configure' takes the directory from the file name that was used to 1273: invoke it. But if you want to be sure, you can specify the source 1274: directory with the `--srcdir' option, like this: 1.1 root 1275: 1.1.1.7 root 1276: ../gcc/configure --srcdir=../gcc OTHER OPTIONS 1.1 root 1277: 1.1.1.3 root 1278: The directory you specify with `--srcdir' need not be the same as 1279: the one that `configure' is found in. 1.1 root 1280: 1281: Now, you can run `make' in that directory. You need not repeat the 1.1.1.3 root 1282: configuration steps shown above, when ordinary source files change. You 1283: must, however, run `configure' again when the configuration files 1.1 root 1284: change, if your system does not support symbolic links. 1285: 1.1.1.3 root 1286: Building and Installing a Cross-Compiler 1.1.1.5 root 1287: ======================================== 1.1.1.3 root 1288: 1289: GNU CC can function as a cross-compiler for many machines, but not 1290: all. 1291: 1.1.1.6 root 1292: * Cross-compilers for the Mips as target using the Mips assembler 1293: currently do not work, because the auxiliary programs 1294: `mips-tdump.c' and `mips-tfile.c' can't be compiled on anything 1295: but a Mips. It does work to cross compile for a Mips if you use 1296: the GNU assembler and linker. 1297: 1298: * Cross-compilers between machines with different floating point 1299: formats have not all been made to work. GNU CC now has a floating 1300: point emulator with which these can work, but each target machine 1301: description needs to be updated to take advantage of it. 1302: 1.1.1.7 root 1303: * Cross-compilation between machines of different word sizes is 1304: somewhat problematic and sometimes does not work. 1.1.1.3 root 1305: 1306: Since GNU CC generates assembler code, you probably need a 1307: cross-assembler that GNU CC can run, in order to produce object files. 1308: If you want to link on other than the target machine, you need a 1309: cross-linker as well. You also need header files and libraries suitable 1310: for the target machine that you can install on the host machine. 1311: 1.1.1.6 root 1312: Steps of Cross-Compilation 1313: -------------------------- 1314: 1315: To compile and run a program using a cross-compiler involves several 1316: steps: 1317: 1318: * Run the cross-compiler on the host machine to produce assembler 1319: files for the target machine. This requires header files for the 1320: target machine. 1321: 1322: * Assemble the files produced by the cross-compiler. You can do this 1323: either with an assembler on the target machine, or with a 1324: cross-assembler on the host machine. 1325: 1326: * Link those files to make an executable. You can do this either 1327: with a linker on the target machine, or with a cross-linker on the 1328: host machine. Whichever machine you use, you need libraries and 1329: certain startup files (typically `crt....o') for the target 1330: machine. 1331: 1332: It is most convenient to do all of these steps on the same host 1333: machine, since then you can do it all with a single invocation of GNU 1334: CC. This requires a suitable cross-assembler and cross-linker. For 1335: some targets, the GNU assembler and linker are available. 1336: 1337: Configuring a Cross-Compiler 1338: ---------------------------- 1339: 1.1.1.3 root 1340: To build GNU CC as a cross-compiler, you start out by running 1.1.1.7 root 1341: `configure'. Use the `--target=TARGET' to specify the target type. If 1342: `configure' was unable to correctly identify the system you are running 1343: on, also specify the `--build=BUILD' option. For example, here is how 1344: to configure for a cross-compiler that produces code for an HP 68030 1345: system running BSD on a system that `configure' can correctly identify: 1.1.1.3 root 1346: 1.1.1.7 root 1347: ./configure --target=m68k-hp-bsd4.3 1.1.1.3 root 1348: 1.1.1.6 root 1349: Tools and Libraries for a Cross-Compiler 1350: ---------------------------------------- 1351: 1352: If you have a cross-assembler and cross-linker available, you should 1353: install them now. Put them in the directory `/usr/local/TARGET/bin'. 1354: Here is a table of the tools you should put in this directory: 1355: 1356: `as' 1357: This should be the cross-assembler. 1358: 1359: `ld' 1360: This should be the cross-linker. 1361: 1362: `ar' 1363: This should be the cross-archiver: a program which can manipulate 1364: archive files (linker libraries) in the target machine's format. 1365: 1366: `ranlib' 1367: This should be a program to construct a symbol table in an archive 1368: file. 1369: 1370: The installation of GNU CC will find these programs in that 1371: directory, and copy or link them to the proper place to for the 1372: cross-compiler to find them when run later. 1373: 1374: The easiest way to provide these files is to build the Binutils 1375: package and GAS. Configure them with the same `--host' and `--target' 1376: options that you use for configuring GNU CC, then build and install 1377: them. They install their executables automatically into the proper 1378: directory. Alas, they do not support all the targets that GNU CC 1379: supports. 1380: 1381: If you want to install libraries to use with the cross-compiler, 1382: such as a standard C library, put them in the directory 1383: `/usr/local/TARGET/lib'; installation of GNU CC copies all all the 1384: files in that subdirectory into the proper place for GNU CC to find 1385: them and link with them. Here's an example of copying some libraries 1386: from a target machine: 1387: 1388: ftp TARGET-MACHINE 1389: lcd /usr/local/TARGET/lib 1390: cd /lib 1391: get libc.a 1392: cd /usr/lib 1393: get libg.a 1394: get libm.a 1395: quit 1396: 1397: The precise set of libraries you'll need, and their locations on the 1398: target machine, vary depending on its operating system. 1399: 1400: Many targets require "start files" such as `crt0.o' and `crtn.o' 1401: which are linked into each executable; these too should be placed in 1402: `/usr/local/TARGET/lib'. There may be several alternatives for 1403: `crt0.o', for use with profiling or other compilation options. Check 1404: your target's definition of `STARTFILE_SPEC' to find out what start 1405: files it uses. Here's an example of copying these files from a target 1406: machine: 1407: 1408: ftp TARGET-MACHINE 1409: lcd /usr/local/TARGET/lib 1410: prompt 1411: cd /lib 1412: mget *crt*.o 1413: cd /usr/lib 1414: mget *crt*.o 1415: quit 1416: 1417: `libgcc.a' and Cross-Compilers 1418: ------------------------------ 1419: 1420: Code compiled by GNU CC uses certain runtime support functions 1421: implicitly. Some of these functions can be compiled successfully with 1422: GNU CC itself, but a few cannot be. These problem functions are in the 1423: source file `libgcc1.c'; the library made from them is called 1424: `libgcc1.a'. 1425: 1426: When you build a native compiler, these functions are compiled with 1427: some other compiler-the one that you use for bootstrapping GNU CC. 1428: Presumably it knows how to open code these operations, or else knows how 1429: to call the run-time emulation facilities that the machine comes with. 1430: But this approach doesn't work for building a cross-compiler. The 1431: compiler that you use for building knows about the host system, not the 1432: target system. 1433: 1434: So, when you build a cross-compiler you have to supply a suitable 1435: library `libgcc1.a' that does the job it is expected to do. 1436: 1437: To compile `libgcc1.c' with the cross-compiler itself does not work. 1438: The functions in this file are supposed to implement arithmetic 1.1.1.8 ! root 1439: operations that GNU CC does not know how to open code for your target 1.1.1.6 root 1440: machine. If these functions are compiled with GNU CC itself, they will 1441: compile into infinite recursion. 1442: 1443: On any given target, most of these functions are not needed. If GNU 1444: CC can open code an arithmetic operation, it will not call these 1445: functions to perform the operation. It is possible that on your target 1446: machine, none of these functions is needed. If so, you can supply an 1447: empty library as `libgcc1.a'. 1448: 1449: Many targets need library support only for multiplication and 1450: division. If you are linking with a library that contains functions for 1451: multiplication and division, you can tell GNU CC to call them directly 1452: by defining the macros `MULSI3_LIBCALL', and the like. These macros 1453: need to be defined in the target description macro file. For some 1454: targets, they are defined already. This may be sufficient to avoid the 1455: need for libgcc1.a; if so, you can supply an empty library. 1456: 1457: Some targets do not have floating point instructions; they need other 1458: functions in `libgcc1.a', which do floating arithmetic. Recent 1459: versions of GNU CC have a file which emulates floating point. With a 1460: certain amount of work, you should be able to construct a floating 1461: point emulator that can be used as `libgcc1.a'. Perhaps future 1462: versions will contain code to do this automatically and conveniently. 1463: That depends on whether someone wants to implement it. 1464: 1.1.1.8 ! root 1465: Some embedded targets come with all the necessary `libgcc1.a' ! 1466: routines written in C or assembler. These targets build `libgcc1.a' ! 1467: automatically and you do not need to do anything special for them. ! 1468: Other embedded targets do not need any `libgcc1.a' routines since all ! 1469: the necessary operations are supported by the hardware. ! 1470: 1.1.1.6 root 1471: If your target system has another C compiler, you can configure GNU 1472: CC as a native compiler on that machine, build just `libgcc1.a' with 1473: `make libgcc1.a' on that machine, and use the resulting file with the 1474: cross-compiler. To do this, execute the following on the target 1475: machine: 1476: 1477: cd TARGET-BUILD-DIR 1.1.1.7 root 1478: ./configure --host=sparc --target=sun3 1.1.1.6 root 1479: make libgcc1.a 1480: 1481: And then this on the host machine: 1482: 1483: ftp TARGET-MACHINE 1484: binary 1485: cd TARGET-BUILD-DIR 1486: get libgcc1.a 1487: quit 1488: 1489: Another way to provide the functions you need in `libgcc1.a' is to 1490: define the appropriate `perform_...' macros for those functions. If 1491: these definitions do not use the C arithmetic operators that they are 1492: meant to implement, you should be able to compile them with the 1493: cross-compiler you are building. (If these definitions already exist 1494: for your target file, then you are all set.) 1495: 1496: To build `libgcc1.a' using the perform macros, use 1497: `LIBGCC1=libgcc1.a OLDCC=./xgcc' when building the compiler. 1498: Otherwise, you should place your replacement library under the name 1499: `libgcc1.a' in the directory in which you will build the 1500: cross-compiler, before you run `make'. 1501: 1502: Cross-Compilers and Header Files 1503: -------------------------------- 1504: 1505: If you are cross-compiling a standalone program or a program for an 1506: embedded system, then you may not need any header files except the few 1507: that are part of GNU CC (and those of your program). However, if you 1508: intend to link your program with a standard C library such as `libc.a', 1509: then you probably need to compile with the header files that go with 1510: the library you use. 1511: 1512: The GNU C compiler does not come with these files, because (1) they 1513: are system-specific, and (2) they belong in a C library, not in a 1.1.1.4 root 1514: compiler. 1515: 1.1.1.6 root 1516: If the GNU C library supports your target machine, then you can get 1517: the header files from there (assuming you actually use the GNU library 1518: when you link your program). 1519: 1520: If your target machine comes with a C compiler, it probably comes 1521: with suitable header files also. If you make these files accessible 1522: from the host machine, the cross-compiler can use them also. 1523: 1524: Otherwise, you're on your own in finding header files to use when 1525: cross-compiling. 1526: 1527: When you have found suitable header files, put them in 1528: `/usr/local/TARGET/include', before building the cross compiler. Then 1529: installation will run fixincludes properly and install the corrected 1530: versions of the header files where the compiler will use them. 1531: 1532: Provide the header files before you build the cross-compiler, because 1533: the build stage actually runs the cross-compiler to produce parts of 1534: `libgcc.a'. (These are the parts that *can* be compiled with GNU CC.) 1535: Some of them need suitable header files. 1536: 1537: Here's an example showing how to copy the header files from a target 1538: machine. On the target machine, do this: 1539: 1540: (cd /usr/include; tar cf - .) > tarfile 1541: 1542: Then, on the host machine, do this: 1543: 1544: ftp TARGET-MACHINE 1545: lcd /usr/local/TARGET/include 1546: get tarfile 1547: quit 1548: tar xf tarfile 1549: 1550: Actually Building the Cross-Compiler 1551: ------------------------------------ 1552: 1.1.1.4 root 1553: Now you can proceed just as for compiling a single-machine compiler 1554: through the step of building stage 1. If you have not provided some 1555: sort of `libgcc1.a', then compilation will give up at the point where 1556: it needs that file, printing a suitable error message. If you do 1557: provide `libgcc1.a', then building the compiler will automatically 1.1.1.8 ! root 1558: compile and link a test program called `libgcc1-test'; if you get ! 1559: errors in the linking, it means that not all of the necessary routines ! 1560: in `libgcc1.a' are available. ! 1561: ! 1562: You must provide the header file `float.h'. One way to do this is ! 1563: to compile `enquire' and run it on your target machine. The job of ! 1564: `enquire' is to run on the target machine and figure out by experiment ! 1565: the nature of its floating point representation. `enquire' records its ! 1566: findings in the header file `float.h'. If you can't produce this file ! 1567: by running `enquire' on the target machine, then you will need to come ! 1568: up with a suitable `float.h' in some other way (or else, avoid using it ! 1569: in your programs). 1.1.1.3 root 1570: 1571: Do not try to build stage 2 for a cross-compiler. It doesn't work to 1572: rebuild GNU CC as a cross-compiler using the cross-compiler, because 1573: that would produce a program that runs on the target machine, not on the 1574: host. For example, if you compile a 386-to-68030 cross-compiler with 1575: itself, the result will not be right either for the 386 (because it was 1576: compiled into 68030 code) or for the 68030 (because it was configured 1577: for a 386 as the host). If you want to compile GNU CC into 68030 code, 1578: whether you compile it on a 68030 or with a cross-compiler on a 386, you 1579: must specify a 68030 as the host when you configure it. 1580: 1.1.1.6 root 1581: To install the cross-compiler, use `make install', as usual. 1582: 1.1 root 1583: Installing GNU CC on the Sun 1.1.1.5 root 1584: ============================ 1585: 1586: On Solaris (version 2.1), do not use the linker or other tools in 1587: `/usr/ucb' to build GNU CC. Use `/usr/ccs/bin'. 1.1 root 1588: 1589: Make sure the environment variable `FLOAT_OPTION' is not set when 1590: you compile `libgcc.a'. If this option were set to `f68881' when 1591: `libgcc.a' is compiled, the resulting code would demand to be linked 1.1.1.3 root 1592: with a special startup file and would not link properly without special 1593: pains. 1.1 root 1594: 1.1.1.3 root 1595: There is a bug in `alloca' in certain versions of the Sun library. 1.1 root 1596: To avoid this bug, install the binaries of GNU CC that were compiled by 1597: GNU CC. They use `alloca' as a built-in function and never the one in 1598: the library. 1599: 1600: Some versions of the Sun compiler crash when compiling GNU CC. The 1.1.1.3 root 1601: problem is a segmentation fault in cpp. This problem seems to be due to 1602: the bulk of data in the environment variables. You may be able to avoid 1603: it by using the following command to compile GNU CC with Sun CC: 1.1 root 1604: 1605: make CC="TERMCAP=x OBJS=x LIBFUNCS=x STAGESTUFF=x cc" 1606: 1607: Installing GNU CC on VMS 1.1.1.5 root 1608: ======================== 1.1 root 1609: 1610: The VMS version of GNU CC is distributed in a backup saveset 1611: containing both source code and precompiled binaries. 1612: 1613: To install the `gcc' command so you can use the compiler easily, in 1.1.1.3 root 1614: the same manner as you use the VMS C compiler, you must install the VMS 1615: CLD file for GNU CC as follows: 1.1 root 1616: 1617: 1. Define the VMS logical names `GNU_CC' and `GNU_CC_INCLUDE' to 1.1.1.4 root 1618: point to the directories where the GNU CC executables 1619: (`gcc-cpp.exe', `gcc-cc1.exe', etc.) and the C include files are 1620: kept respectively. This should be done with the commands: 1.1 root 1621: 1.1.1.2 root 1622: $ assign /system /translation=concealed - 1623: disk:[gcc.] gnu_cc 1624: $ assign /system /translation=concealed - 1625: disk:[gcc.include.] gnu_cc_include 1.1 root 1626: 1.1.1.3 root 1627: with the appropriate disk and directory names. These commands can 1628: be placed in your system startup file so they will be executed 1629: whenever the machine is rebooted. You may, if you choose, do this 1630: via the `GCC_INSTALL.COM' script in the `[GCC]' directory. 1.1 root 1631: 1632: 2. Install the `GCC' command with the command line: 1633: 1.1.1.2 root 1634: $ set command /table=sys$common:[syslib]dcltables - 1635: /output=sys$common:[syslib]dcltables gnu_cc:[000000]gcc 1636: $ install replace sys$common:[syslib]dcltables 1.1 root 1637: 1638: 3. To install the help file, do the following: 1639: 1.1.1.4 root 1640: $ library/help sys$library:helplib.hlb gcc.hlp 1.1 root 1641: 1642: Now you can invoke the compiler with a command like `gcc /verbose 1643: file.c', which is equivalent to the command `gcc -v -c file.c' in 1644: Unix. 1645: 1646: If you wish to use GNU C++ you must first install GNU CC, and then 1647: perform the following steps: 1648: 1649: 1. Define the VMS logical name `GNU_GXX_INCLUDE' to point to the 1650: directory where the preprocessor will search for the C++ header 1.1.1.5 root 1651: files. This can be done with the command: 1.1 root 1652: 1.1.1.2 root 1653: $ assign /system /translation=concealed - 1654: disk:[gcc.gxx_include.] gnu_gxx_include 1.1 root 1655: 1.1.1.3 root 1656: with the appropriate disk and directory name. If you are going to 1657: be using libg++, this is where the libg++ install procedure will 1658: install the libg++ header files. 1.1 root 1659: 1660: 2. Obtain the file `gcc-cc1plus.exe', and place this in the same 1661: directory that `gcc-cc1.exe' is kept. 1662: 1.1.1.3 root 1663: The GNU C++ compiler can be invoked with a command like `gcc /plus 1664: /verbose file.cc', which is equivalent to the command `g++ -v -c 1665: file.cc' in Unix. 1.1 root 1666: 1667: We try to put corresponding binaries and sources on the VMS 1668: distribution tape. But sometimes the binaries will be from an older 1.1.1.4 root 1669: version than the sources, because we don't always have time to update 1.1 root 1670: them. (Use the `/version' option to determine the version number of 1671: the binaries and compare it with the source file `version.c' to tell 1.1.1.3 root 1672: whether this is so.) In this case, you should use the binaries you get 1673: to recompile the sources. If you must recompile, here is how: 1.1 root 1674: 1.1.1.5 root 1675: 1. Execute the command procedure `vmsconfig.com' to set up the files 1676: `tm.h', `config.h', `aux-output.c', and `md.', and to create files 1677: `tconfig.h' and `hconfig.h'. This procedure also creates several 1678: linker option files used by `make-cc1.com' and a data file used by 1679: `make-l2.com'. 1.1.1.4 root 1680: 1681: $ @vmsconfig.com 1.1 root 1682: 1683: 2. Setup the logical names and command tables as defined above. In 1684: addition, define the VMS logical name `GNU_BISON' to point at the 1685: to the directories where the Bison executable is kept. This 1686: should be done with the command: 1687: 1.1.1.2 root 1688: $ assign /system /translation=concealed - 1689: disk:[bison.] gnu_bison 1.1 root 1690: 1.1.1.3 root 1691: You may, if you choose, use the `INSTALL_BISON.COM' script in the 1692: `[BISON]' directory. 1.1 root 1693: 1694: 3. Install the `BISON' command with the command line: 1695: 1.1.1.2 root 1696: $ set command /table=sys$common:[syslib]dcltables - 1697: /output=sys$common:[syslib]dcltables - 1698: gnu_bison:[000000]bison 1699: $ install replace sys$common:[syslib]dcltables 1.1 root 1700: 1.1.1.5 root 1701: 4. Type `@make-gcc' to recompile everything (alternatively, submit 1702: the file `make-gcc.com' to a batch queue). If you wish to build 1703: the GNU C++ compiler as well as the GNU CC compiler, you must 1.1.1.3 root 1704: first edit `make-gcc.com' and follow the instructions that appear 1705: in the comments. 1.1 root 1706: 1.1.1.2 root 1707: 5. In order to use GCC, you need a library of functions which GCC 1708: compiled code will call to perform certain tasks, and these 1709: functions are defined in the file `libgcc2.c'. To compile this 1710: you should use the command procedure `make-l2.com', which will 1.1.1.5 root 1711: generate the library `libgcc2.olb'. `libgcc2.olb' should be built 1.1.1.3 root 1712: using the compiler built from the same distribution that 1.1.1.2 root 1713: `libgcc2.c' came from, and `make-gcc.com' will automatically do 1714: all of this for you. 1715: 1.1.1.3 root 1716: To install the library, use the following commands: 1.1.1.2 root 1717: 1.1.1.4 root 1718: $ library gnu_cc:[000000]gcclib/delete=(new,eprintf) 1.1.1.5 root 1719: $ library gnu_cc:[000000]gcclib/delete=L_* 1.1.1.4 root 1720: $ library libgcc2/extract=*/output=libgcc2.obj 1721: $ library gnu_cc:[000000]gcclib libgcc2.obj 1.1.1.2 root 1722: 1.1.1.3 root 1723: The first command simply removes old modules that will be replaced 1.1.1.5 root 1724: with modules from `libgcc2' under different module names. The 1725: modules `new' and `eprintf' may not actually be present in your 1726: `gcclib.olb'--if the VMS librarian complains about those modules 1727: not being present, simply ignore the message and continue on with 1728: the next command. The second command removes the modules that 1729: came from the previous version of the library `libgcc2.c'. 1.1.1.3 root 1730: 1731: Whenever you update the compiler on your system, you should also 1732: update the library with the above procedure. 1733: 1.1.1.4 root 1734: 6. You may wish to build GCC in such a way that no files are written 1.1.1.3 root 1735: to the directory where the source files reside. An example would 1736: be the when the source files are on a read-only disk. In these 1737: cases, execute the following DCL commands (substituting your 1738: actual path names): 1739: 1.1.1.4 root 1740: $ assign dua0:[gcc.build_dir.]/translation=concealed, - 1741: dua1:[gcc.source_dir.]/translation=concealed gcc_build 1.1.1.3 root 1742: $ set default gcc_build:[000000] 1743: 1.1.1.5 root 1744: where the directory `dua1:[gcc.source_dir]' contains the source 1745: code, and the directory `dua0:[gcc.build_dir]' is meant to contain 1746: all of the generated object files and executables. Once you have 1747: done this, you can proceed building GCC as described above. (Keep 1748: in mind that `gcc_build' is a rooted logical name, and thus the 1749: device names in each element of the search list must be an actual 1750: physical device name rather than another rooted logical name). 1.1.1.3 root 1751: 1.1.1.4 root 1752: 7. *If you are building GNU CC with a previous version of GNU CC, you 1.1.1.3 root 1753: also should check to see that you have the newest version of the 1754: assembler*. In particular, GNU CC version 2 treats global constant 1755: variables slightly differently from GNU CC version 1, and GAS 1756: version 1.38.1 does not have the patches required to work with GCC 1.1.1.5 root 1757: version 2. If you use GAS 1.38.1, then `extern const' variables 1.1.1.3 root 1758: will not have the read-only bit set, and the linker will generate 1759: warning messages about mismatched psect attributes for these 1760: variables. These warning messages are merely a nuisance, and can 1761: safely be ignored. 1.1 root 1762: 1.1.1.3 root 1763: If you are compiling with a version of GNU CC older than 1.33, 1.1 root 1764: specify `/DEFINE=("inline=")' as an option in all the 1765: compilations. This requires editing all the `gcc' commands in 1.1.1.5 root 1766: `make-cc1.com'. (The older versions had problems supporting 1.1 root 1767: `inline'.) Once you have a working 1.33 or newer GNU CC, you can 1768: change this file back. 1769: 1.1.1.4 root 1770: 8. If you want to build GNU CC with the VAX C compiler, you will need 1771: to make minor changes in `make-cccp.com' and `make-cc1.com' to 1772: choose alternate definitions of `CC', `CFLAGS', and `LIBS'. See 1773: comments in those files. However, you must also have a working 1774: version of the GNU assembler (GNU as, aka GAS) as it is used as 1775: the back-end for GNU CC to produce binary object modules and is 1776: not included in the GNU CC sources. GAS is also needed to compile 1777: `libgcc2' in order to build `gcclib' (see above); `make-l2.com' 1778: expects to be able to find it operational in 1779: `gnu_cc:[000000]gnu-as.exe'. 1780: 1781: To use GNU CC on VMS, you need the VMS driver programs `gcc.exe', 1782: `gcc.com', and `gcc.cld'. They are distributed with the VMS 1783: binaries (`gcc-vms') rather than the GNU CC sources. GAS is also 1784: included in `gcc-vms', as is Bison. 1785: 1786: Once you have successfully built GNU CC with VAX C, you should use 1787: the resulting compiler to rebuild itself. Before doing this, be 1788: sure to restore the `CC', `CFLAGS', and `LIBS' definitions in 1789: `make-cccp.com' and `make-cc1.com'. The second generation 1790: compiler will be able to take advantage of many optimizations that 1791: must be suppressed when building with other compilers. 1792: 1.1 root 1793: Under previous versions of GNU CC, the generated code would 1.1.1.4 root 1794: occasionally give strange results when linked with the sharable 1.1.1.5 root 1795: `VAXCRTL' library. Now this should work. 1.1 root 1796: 1797: Even with this version, however, GNU CC itself should not be linked 1.1.1.4 root 1798: with the sharable `VAXCRTL'. The version of `qsort' in `VAXCRTL' has a 1799: bug (known to be present in VMS versions V4.6 through V5.5) which 1800: causes the compiler to fail. 1.1 root 1801: 1.1.1.5 root 1802: The executables are generated by `make-cc1.com' and `make-cccp.com' 1803: use the object library version of `VAXCRTL' in order to make use of the 1804: `qsort' routine in `gcclib.olb'. If you wish to link the compiler 1805: executables with the shareable image version of `VAXCRTL', you should 1806: edit the file `tm.h' (created by `vmsconfig.com') to define the macro 1807: `QSORT_WORKAROUND'. 1.1.1.4 root 1808: 1809: `QSORT_WORKAROUND' is always defined when GNU CC is compiled with 1810: VAX C, to avoid a problem in case `gcclib.olb' is not yet available. 1811: 1.1.1.5 root 1812: `collect2' 1813: ========== 1814: 1815: Many target systems do not have support in the assembler and linker 1816: for "constructors"--initialization functions to be called before the 1817: official "start" of `main'. On such systems, GNU CC uses a utility 1818: called `collect2' to arrange to call these functions at start time. 1819: 1820: The program `collect2' works by linking the program once and looking 1821: through the linker output file for symbols with particular names 1822: indicating they are constructor functions. If it finds any, it creates 1823: a new temporary `.c' file containing a table of them, compiles it, and 1824: links the program a second time including that file. 1825: 1826: The actual calls to the constructors are carried out by a subroutine 1827: called `__main', which is called (automatically) at the beginning of 1.1.1.7 root 1828: the body of `main' (provided `main' was compiled with GNU CC). Calling 1829: `__main' is necessary, even when compiling C code, to allow linking C 1830: and C++ object code together. (If you use `-nostdlib', you get an 1831: unresolved reference to `__main', since it's defined in the standard 1832: GCC library. Include `-lgcc' at the end of your compiler command line 1833: to resolve this reference.) 1.1.1.5 root 1834: 1835: The program `collect2' is installed as `ld' in the directory where 1836: the passes of the compiler are installed. When `collect2' needs to 1837: find the *real* `ld', it tries the following file names: 1838: 1.1.1.7 root 1839: * `real-ld' in the directories listed in the compiler's search 1.1.1.5 root 1840: directories. 1841: 1.1.1.7 root 1842: * `real-ld' in the directories listed in the environment variable 1843: `PATH'. 1.1.1.5 root 1844: 1.1.1.7 root 1845: * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 1846: if specified. 1.1.1.5 root 1847: 1.1.1.7 root 1848: * `ld' in the compiler's search directories, except that `collect2' 1849: will not execute itself recursively. 1.1.1.5 root 1850: 1851: * `ld' in `PATH'. 1852: 1853: "The compiler's search directories" means all the directories where 1854: `gcc' searches for passes of the compiler. This includes directories 1855: that you specify with `-B'. 1856: 1.1.1.6 root 1857: Cross-compilers search a little differently: 1.1.1.5 root 1858: 1859: * `real-ld' in the compiler's search directories. 1860: 1861: * `TARGET-real-ld' in `PATH'. 1862: 1.1.1.7 root 1863: * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 1864: if specified. 1865: 1866: * `ld' in the compiler's search directories. 1867: 1.1.1.5 root 1868: * `TARGET-ld' in `PATH'. 1869: 1.1.1.7 root 1870: `collect2' explicitly avoids running `ld' using the file name under 1871: which `collect2' itself was invoked. In fact, it remembers up a list 1872: of such names--in case one copy of `collect2' finds another copy (or 1873: version) of `collect2' installed as `ld' in a second place in the 1874: search path. 1.1.1.5 root 1875: 1.1.1.7 root 1876: `collect2' searches for the utilities `nm' and `strip' using the 1877: same algorithm as above for `ld'. 1.1.1.5 root 1878: 1.1.1.6 root 1879: Standard Header File Directories 1880: ================================ 1881: 1882: `GCC_INCLUDE_DIR' means the same thing for native and cross. It is 1883: where GNU CC stores its private include files, and also where GNU CC 1884: stores the fixed include files. A cross compiled GNU CC runs 1885: `fixincludes' on the header files in `$(tooldir)/include'. (If the 1886: cross compilation header files need to be fixed, they must be installed 1887: before GNU CC is built. If the cross compilation header files are 1888: already suitable for ANSI C and GNU CC, nothing special need be done). 1889: 1890: `GPLUS_INCLUDE_DIR' means the same thing for native and cross. It 1891: is where `g++' looks first for header files. `libg++' installs only 1892: target independent header files in that directory. 1893: 1894: `LOCAL_INCLUDE_DIR' is used only for a native compiler. It is 1895: normally `/usr/local/include'. GNU CC searches this directory so that 1896: users can install header files in `/usr/local/include'. 1897: 1898: `CROSS_INCLUDE_DIR' is used only for a cross compiler. GNU CC 1899: doesn't install anything there. 1900: 1901: `TOOL_INCLUDE_DIR' is used for both native and cross compilers. It 1902: is the place for other packages to install header files that GNU CC will 1903: use. For a cross-compiler, this is the equivalent of `/usr/include'. 1904: When you build a cross-compiler, `fixincludes' processes any header 1905: files in this directory. 1906:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.