![[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 ! 2: (C) 1988, 1989, 1992 Free Software Foundation, Inc. You may copy, 1.1.1.3 root 3: distribute, and modify it freely as long as you preserve this copyright 4: notice and permission notice. 1.1 root 5: 6: Installing GNU CC 1.1.1.5 ! root 7: ***************** 1.1 root 8: 9: Here is the procedure for installing GNU CC on a Unix system. 10: 11: 1. If you have built GNU CC previously in the same directory for a 1.1.1.2 root 12: different target machine, do `make distclean' to delete all files 1.1.1.4 root 13: that might be invalid. One of the files this deletes is 14: `Makefile'; if `make distclean' complains that `Makefile' does not 15: exist, it probably means that the directory is already suitably 16: clean. 1.1 root 17: 1.1.1.3 root 18: 2. On a System V release 4 system, make sure `/usr/bin' precedes 1.1 root 19: `/usr/ucb' in `PATH'. The `cc' command in `/usr/ucb' uses 20: libraries which have bugs. 21: 1.1.1.3 root 22: 3. Specify the host and target machine configurations. You do this by 23: running the file `configure' with appropriate arguments. 1.1 root 24: 1.1.1.3 root 25: If you are building a compiler to produce code for the machine it 26: runs on, specify just one machine type. Use the `--target' 1.1.1.5 ! root 27: option; the host type will default to be the same as the target. 1.1.1.3 root 28: (For information on building a cross-compiler, see *Note 29: Cross-Compiler::.) The command looks like this: 1.1 root 30: 1.1.1.3 root 31: configure --target=sparc-sun-sunos4.1 1.1 root 32: 1.1.1.3 root 33: A configuration name may be canonical or it may be more or less 1.1 root 34: abbreviated. 35: 1.1.1.3 root 36: A canonical configuration name has three parts, separated by 1.1.1.5 ! root 37: dashes. It looks like this: `CPU-COMPANY-SYSTEM'. (The three ! 38: parts may themselves contain dashes; `configure' can figure out ! 39: which dashes serve which purpose.) For example, ! 40: `m68k-sun-sunos4.1' specifies a Sun 3. 1.1 root 41: 1.1.1.3 root 42: You can also replace parts of the configuration by nicknames or 1.1.1.5 ! root 43: aliases. For example, `sun3' stands for `m68k-sun', so 1.1 root 44: `sun3-sunos4.1' is another way to specify a Sun 3. You can also 1.1.1.2 root 45: use simply `sun3-sunos', since the version of SunOS is assumed by 1.1.1.3 root 46: default to be version 4. `sun3-bsd' also works, since `configure' 47: knows that the only BSD variant on a Sun 3 is SunOS. 48: 49: You can specify a version number after any of the system types, 50: and some of the CPU types. In most cases, the version is 51: irrelevant, and will be ignored. So you might as well specify the 52: version if you know it. 1.1 root 53: 1.1.1.3 root 54: Here are the possible CPU types: 55: 1.1.1.5 ! root 56: a29k, alpha, arm, cN, clipper, elxsi, h8300, hppa1.0, hppa1.1, ! 57: i386, i860, i960, m68000, m68k, m88k, mips, ns32k, pyramid, ! 58: romp, rs6000, sh, sparc, sparclite, vax, we32k. 1.1.1.3 root 59: 60: Here are the recognized company names. As you can see, customary 61: abbreviations are used rather than the longer official names. 1.1 root 62: 1.1.1.5 ! root 63: alliant, altos, apollo, att, bull, cbm, convergent, convex, ! 64: crds, dec, dg, dolphin, elxsi, encore, harris, hitachi, hp, ! 65: ibm, intergraph, isi, mips, motorola, ncr, next, ns, omron, ! 66: plexus, sequent, sgi, sony, sun, tti, unicom. 1.1 root 67: 1.1.1.3 root 68: The company name is meaningful only to disambiguate when the rest 69: of the information supplied is insufficient. You can omit it, 70: writing just `CPU-SYSTEM', if it is not needed. For example, 1.1 root 71: `vax-ultrix4.2' is equivalent to `vax-dec-ultrix4.2'. 72: 1.1.1.3 root 73: Here is a list of system types: 1.1 root 74: 1.1.1.5 ! root 75: aix, acis, aos, bsd, clix, ctix, dgux, dynix, genix, hpux, ! 76: isc, linux, luna, mach, minix, newsos, osf, osfrose, riscos, ! 77: sco, solaris, sunos, sysv, ultrix, unos, vms. 1.1 root 78: 79: You can omit the system type; then `configure' guesses the 80: operating system from the CPU and company. 81: 1.1.1.3 root 82: You can add a version number to the system type; this may or may 83: not make a difference. For example, you can write `bsd4.3' or 1.1.1.2 root 84: `bsd4.4' to distinguish versions of BSD. In practice, the version 85: number is most needed for `sysv3' and `sysv4', which are often 86: treated differently. 87: 1.1.1.3 root 88: If you specify an impossible combination such as `i860-dg-vms', 1.1.1.2 root 89: then you may get an error message from `configure', or it may 90: ignore part of the information and do the best it can with the 1.1.1.5 ! root 91: rest. `configure' always prints the canonical name for the 1.1.1.2 root 92: alternative that it used. 93: 1.1.1.3 root 94: Often a particular model of machine has a name. Many machine 1.1.1.5 ! root 95: names are recognized as aliases for CPU/company combinations. 1.1.1.2 root 96: Thus, the machine name `sun3', mentioned above, is an alias for 1.1.1.5 ! root 97: `m68k-sun'. Sometimes we accept a company name as a machine name, 1.1.1.3 root 98: when the name is popularly used for a particular machine. Here is 99: a table of the known machine names: 100: 101: 3300, 3b1, 3bN, 7300, altos3068, altos, apollo68, att-7300, 102: balance, convex-cN, crds, decstation-3100, decstation, delta, 103: encore, fx2800, gmicro, hp7NN, hp8NN, hp9k2NN, hp9k3NN, 104: hp9k7NN, hp9k8NN, iris4d, iris, isi68, m3230, magnum, merlin, 105: miniframe, mmax, news-3600, news800, news, next, pbd, pc532, 106: pmax, ps2, risc-news, rtpc, sun2, sun386i, sun386, sun3, 107: sun4, symmetry, tower-32, tower. 1.1 root 108: 1.1.1.2 root 109: Remember that a machine name specifies both the cpu type and the 110: company name. 1.1 root 111: 1.1.1.4 root 112: There are four additional options you can specify independently to 1.1.1.3 root 113: describe variant hardware and software configurations. These are 1.1.1.4 root 114: `--with-gnu-as', `--with-gnu-ld', `--with-stabs' and `--nfp'. 1.1.1.3 root 115: 116: `--with-gnu-as' 1.1.1.5 ! root 117: If you will use GNU CC with the GNU assembler (GAS), you ! 118: should declare this by using the `--with-gnu-as' option when ! 119: you run `configure'. ! 120: ! 121: Using this option does not install GAS. It only modifies the ! 122: output of GNU CC to work with GAS. Building and installing ! 123: GAS is up to you. ! 124: ! 125: The systems where it makes a difference whether you use GAS ! 126: are `i386-ANYTHING-sysv', `i860-ANYTHING-bsd', ! 127: `m68k-hp-hpux', `m68k-sony-bsd', `m68k-altos-sysv', ! 128: `m68000-hp-hpux', `m68000-att-sysv', and `mips-ANY'). On any ! 129: other system, `--with-gnu-as' has no effect. ! 130: ! 131: On the systems listed above, if you use GAS, you should also ! 132: use the GNU linker (and specify `--with-gnu-ld'). 1.1.1.3 root 133: 134: `--with-gnu-ld' 135: Specify the option `--with-gnu-ld' if you plan to use the GNU 1.1.1.5 ! root 136: linker with GNU CC. ! 137: ! 138: This option does not cause the GNU linker to be installed; it ! 139: just modifies the behavior of GNU CC to work with the GNU ! 140: linker. Specifically, it inhibits the installation of ! 141: `collect2', a program which otherwise serves as a front-end ! 142: for the system's linker on most configurations. 1.1.1.3 root 143: 1.1.1.4 root 144: `--with-stabs' 145: On MIPS based systems, you must specify whether you want GNU 146: CC to create the normal ECOFF debugging format, or to use 147: BSD-style stabs passed through the ECOFF symbol table. The 148: normal ECOFF debug format cannot fully handle languages other 149: than C. BSD stabs format can handle other languages, but it 150: only works with the GNU debugger GDB. 151: 152: Normally, GNU CC uses the ECOFF debugging format by default; 153: if you prefer BSD stabs, specify `--with-stabs' when you 154: configure GNU CC. 155: 156: No matter which default you choose when you configure GNU CC, 157: the user can use the `-gcoff' and `-gstabs+' options to 158: specify explicitly the debug format for a particular 159: compilation. 160: 1.1.1.3 root 161: `--nfp' 162: On certain systems, you must specify whether the machine has 1.1.1.5 ! root 163: a floating point unit. These systems include ! 164: `m68k-sun-sunosN' and `m68k-isi-bsd'. On any other system, ! 165: `--nfp' currently has no effect, though perhaps there are ! 166: other systems where it could usefully make a difference. 1.1.1.3 root 167: 168: If you want to install your own homemade configuration files, you 169: can use `local' as the company name to access them. If you use 1.1.1.5 ! root 170: configuration `CPU-local', the configuration name without the cpu ! 171: prefix is used to form the configuration file names. 1.1 root 172: 1.1.1.5 ! root 173: Thus, if you specify `m68k-local', configuration uses files ! 174: `local.md', `local.h', `local.c', `xm-local.h', `t-local', and ! 175: `x-local', all in the directory `config/m68k'. 1.1 root 176: 1.1.1.3 root 177: Here is a list of configurations that have special treatment or 178: special things you must know: 1.1.1.2 root 179: 1.1.1.4 root 180: `alpha-*-osf1' 181: Systems using processors that implement the DEC Alpha 1.1.1.5 ! root 182: architecture and are running the OSF/1 operating system, for ! 183: example the DEC Alpha AXP systems. (VMS on the Alpha is not ! 184: currently supported by GNU CC.) ! 185: ! 186: GNU CC writes a `.verstamp' directive to the assembler output ! 187: file unless it is built as a cross-compiler. It gets the ! 188: version to use from the system header file ! 189: `/usr/include/stamp.h'. If you install a new version of ! 190: OSF/1, you should rebuild GCC to pick up the new version ! 191: stamp. 1.1.1.4 root 192: 193: Note that since the Alpha is a 64-bit architecture, 194: cross-compilers from 32-bit machines will not generate as 195: efficient code as that generated when the compiler is running 196: on a 64-bit machine because many optimizations that depend on 197: being able to represent a word on the target in an integral 1.1.1.5 ! root 198: value on the host cannot be performed. Building ! 199: cross-compilers for 32-bit machines that run on the Alpha has ! 200: not been tested and may not work properly. 1.1.1.4 root 201: 202: `a29k' 1.1.1.5 ! root 203: AMD Am29k-family processors. These are normally used in 1.1.1.4 root 204: embedded applications. There are no standard Unix 1.1.1.5 ! root 205: configurations. This configuration corresponds to AMD's 1.1.1.4 root 206: standard calling sequence and binary interface and is 1.1.1.5 ! root 207: compatible with other 29k tools. 1.1.1.4 root 208: 209: You may need to make a variant of the file `a29k.h' for your 210: particular configuration. 211: 212: `a29k-*-bsd' 213: AMD Am29050 used in a system running a variant of BSD Unix. 214: 215: `elxsi-elxsi-bsd' 216: The Elxsi's C compiler has known limitations that prevent it 217: from compiling GNU C. Please contact `[email protected]' for 218: more details. 219: 1.1.1.2 root 220: `i386-*-sco' 1.1.1.5 ! root 221: Compilation with RCC is recommended. Also, it may be a good ! 222: idea to link with GNU malloc instead of the malloc that comes ! 223: with the system. ! 224: ! 225: `i386-*-isc' ! 226: It may be good idea to link with GNU malloc instead of the ! 227: malloc that comes with the system. ! 228: ! 229: `i386-*-esix' ! 230: It may be good idea to link with GNU malloc instead of the ! 231: malloc that comes with the system. 1.1.1.4 root 232: 233: `i386-ibm-aix' 1.1.1.5 ! root 234: You need to use GAS version 2.1 or later, and and LD from GNU ! 235: binutils version 2.2 or later. 1.1 root 236: 1.1.1.3 root 237: `i386-sequent' 238: Go to the Berkeley universe before compiling. In addition, 239: you probably need to create a file named `string.h' 240: containing just one line: `#include <strings.h>'. 241: 1.1.1.4 root 242: `i386-sun-sunos4' 243: You may find that you need another version of GNU CC to begin 244: bootstrapping with, since the current version when built with 245: the system's own compiler seems to get an infinite loop 246: compiling part of `libgcc2.c'. GNU CC version 2 compiled 247: with GNU CC (any version) seems not to have this problem. 248: 1.1 root 249: `m68000-att' 250: AT&T 3b1, a.k.a. 7300 PC. Special procedures are needed to 251: compile GNU CC with this machine's standard C compiler, due 252: to bugs in that compiler. *Note 3b1 Install::. You can 253: bootstrap it more easily with previous versions of GNU CC if 254: you have them. 255: 256: `m68000-hp-bsd' 257: HP 9000 series 200 running BSD. Note that the C compiler 258: that comes with this system cannot compile GNU CC; contact 1.1.1.3 root 259: `[email protected]' to get binaries of GNU CC for bootstrapping. 1.1 root 260: 261: `m68k-altos' 262: Altos 3068. You must use the GNU assembler, linker and 1.1.1.5 ! root 263: debugger. Also, you must fix a kernel bug. Details in the ! 264: file `README.ALTOS'. 1.1 root 265: 266: `m68k-hp-hpux' 1.1.1.2 root 267: HP 9000 series 300 or 400 running HP-UX. HP-UX version 8.0 268: has a bug in the assembler that prevents compilation of GNU 269: CC. To fix it, get patch PHCO_0800 from HP. 270: 271: In addition, `--gas' does not currently work with this 272: configuration. Changes in HP-UX have broken the library 273: conversion tool and the linker. 1.1 root 274: 275: `m68k-sun' 1.1.1.3 root 276: Sun 3. We do not provide a configuration file to use the Sun 277: FPA by default, because programs that establish signal 278: handlers for floating point traps inherently cannot work with 279: the FPA. 280: 1.1.1.5 ! root 281: `m88k-*-svr3' 1.1.1.4 root 282: Motorola m88k running the AT&T/Unisoft/Motorola V.3 reference 1.1.1.5 ! root 283: port. These systems tend to use the Green Hills C, revision 1.1.1.3 root 284: 1.8.5, as the standard C compiler. There are apparently bugs 285: in this compiler that result in object files differences 286: between stage 2 and stage 3. If this happens, make the stage 287: 4 compiler and compare it to the stage 3 compiler. If the 288: stage 3 and stage 4 object files are identical, this suggests 1.1.1.5 ! root 289: you encountered a problem with the standard C compiler; the ! 290: stage 3 and 4 compilers may be usable. ! 291: ! 292: It is best, however, to use an older version of GNU CC for ! 293: bootstrapping if you have one. 1.1 root 294: 1.1.1.5 ! root 295: `m88k-*-dgux' 1.1 root 296: Motorola m88k running DG/UX. To build native or cross 297: compilers on DG/UX, you must first change to the 88open BCS 298: software development environment. This is done by issuing 299: this command: 300: 301: eval `sde-target m88kbcs` 302: 1.1.1.5 ! root 303: `m88k-tektronix-sysv3' ! 304: Tektronix XD88 running UTekV 3.2e. Do not turn on ! 305: optimization while building stage1 if you bootstrap with the ! 306: buggy Green Hills compiler. Also, The bundled LAI System V ! 307: NFS is buggy so if you build in an NFS mounted directory, ! 308: start from a fresh reboot, or avoid NFS all together. ! 309: Otherwise you may have trouble getting clean comparisons ! 310: between stages. ! 311: 1.1.1.2 root 312: `mips-mips-bsd' 1.1.1.5 ! root 313: MIPS machines running the MIPS operating system in BSD mode. 1.1.1.3 root 314: It's possible that some old versions of the system lack the 1.1.1.2 root 315: functions `memcpy', `memcmp', and `memset'. If your system 316: lacks these, you must remove or undo the definition of 317: `TARGET_MEM_FUNCTIONS' in `mips-bsd.h'. 318: 1.1.1.5 ! root 319: `mips-sgi-*' ! 320: Silicon Graphics MIPS machines running IRIX. In order to ! 321: compile GCC on an SGI the "c.hdr.lib" option must be ! 322: installed from the CD-ROM supplied from Silicon Graphics. ! 323: This is found on the 2nd CD in release 4.0.1. ! 324: 1.1.1.3 root 325: `mips-sony-sysv' 326: Sony MIPS NEWS. This works in NEWSOS 5.0.1, but not in 5.0.2 327: (which uses ELF instead of COFF). Support for 5.0.2 will 1.1.1.5 ! root 328: probably be provided soon by volunteers. In particular, the ! 329: linker does not like the code generated by GCC when shared ! 330: libraries are linked in. 1.1.1.3 root 331: 1.1 root 332: `ns32k-encore' 333: Encore ns32000 system. Encore systems are supported only 334: under BSD. 335: 336: `ns32k-*-genix' 337: National Semiconductor ns32000 system. Genix has bugs in 338: `alloca' and `malloc'; you must get the compiled versions of 339: these from GNU Emacs. 340: 1.1.1.3 root 341: `ns32k-sequent' 342: Go to the Berkeley universe before compiling. In addition, 343: you probably need to create a file named `string.h' 344: containing just one line: `#include <strings.h>'. 345: 1.1 root 346: `ns32k-utek' 347: UTEK ns32000 system ("merlin"). The C compiler that comes 348: with this system cannot compile GNU CC; contact 349: `tektronix!reed!mason' to get binaries of GNU CC for 350: bootstrapping. 351: 1.1.1.3 root 352: `romp-*-aos' 353: `romp-*-mach' 354: The only operating systems supported for the IBM RT PC are 355: AOS and MACH. GNU CC does not support AIX running on the RT. 1.1.1.5 ! root 356: We recommend you compile GNU CC with an earlier version of 1.1.1.4 root 357: itself; if you compile GNU CC with `hc', the Metaware 358: compiler, it will work, but you will get mismatches between 1.1.1.5 ! root 359: the stage 2 and stage 3 compilers in various files. These 1.1.1.4 root 360: errors are minor differences in some floating-point constants 361: and can be safely ignored; the stage 3 compiler is correct. 1.1.1.3 root 362: 363: `rs6000-*-aix' 1.1.1.4 root 364: *Read the file `README.RS6000' for information on how to get 1.1.1.5 ! root 365: a fix for problems in the IBM assembler that interfere with 1.1.1.4 root 366: GNU CC.* You must either obtain the new assembler or avoid 367: using the `-g' switch. Note that `Makefile.in' uses `-g' by 368: default when compiling `libgcc2.c'. 1.1 root 369: 370: `vax-dec-ultrix' 371: Don't try compiling with Vax C (`vcc'). It produces 372: incorrect code in some cases (for example, when `alloca' is 373: used). 374: 375: Meanwhile, compiling `cp-parse.c' with pcc does not work 376: because of an internal table size limitation in that 377: compiler. To avoid this problem, compile just the GNU C 378: compiler first, and use it to recompile building all the 379: languages that you want to run. 380: 1.1.1.5 ! root 381: Here we spell out what files will be set up by `configure'. 1.1 root 382: Normally you need not be concerned with these files. 383: 384: * A symbolic link named `config.h' is made to the top-level 1.1.1.3 root 385: config file for the machine you plan to run the compiler on 386: (*note The Configuration File: (gcc.info)Config.). This file 387: is responsible for defining information about the host 388: machine. It includes `tm.h'. 1.1 root 389: 390: The top-level config file is located in the subdirectory 1.1.1.5 ! root 391: `config'. Its name is always `xm-SOMETHING.h'; usually 1.1 root 392: `xm-MACHINE.h', but there are some exceptions. 393: 394: If your system does not support symbolic links, you might 395: want to set up `config.h' to contain a `#include' command 396: which refers to the appropriate file. 397: 398: * A symbolic link named `tconfig.h' is made to the top-level 399: config file for your target machine. This is used for 400: compiling certain programs to run on that machine. 401: 402: * A symbolic link named `tm.h' is made to the 403: machine-description macro file for your target machine. It 404: should be in the subdirectory `config' and its name is often 405: `MACHINE.h'. 406: 407: * A symbolic link named `md' will be made to the machine 408: description pattern file. It should be in the `config' 1.1.1.3 root 409: subdirectory and its name should be `MACHINE.md'; but MACHINE 410: is often not the same as the name used in the `tm.h' file 411: because the `md' files are more general. 1.1 root 412: 413: * A symbolic link named `aux-output.c' will be made to the 1.1.1.3 root 414: output subroutine file for your machine. It should be in the 415: `config' subdirectory and its name should be `MACHINE.c'. 1.1 root 416: 1.1.1.5 ! root 417: * The command file `configure' also constructs the file ! 418: `Makefile' by adding some text to the template file ! 419: `Makefile.in'. The additional text comes from files in the ! 420: `config' directory, named `t-TARGET' and `x-HOST'. If these ! 421: files do not exist, it means nothing needs to be added for a ! 422: given target or host. ! 423: ! 424: 4. The standard directory for installing GNU CC is `/usr/local/lib'. ! 425: If you want to install its files somewhere else, specify ! 426: `--prefix=DIR' when you run `configure'. Here DIR is a directory ! 427: name to use instead of `/usr/local' for all purposes with one ! 428: exception: the directory `/usr/local/include' is searched for ! 429: header files no matter where you install the compiler. ! 430: ! 431: 5. Specify `--local-prefix=DIR' if you want the compiler to search ! 432: directory `DIR/include' for header files *instead* of ! 433: `/usr/local/include'. (This is for systems that have different ! 434: conventions for where to put site-specific things.) 1.1 root 435: 1.1.1.5 ! root 436: 6. Make sure the Bison parser generator is installed. (This is 1.1.1.3 root 437: unnecessary if the Bison output files `c-parse.c' and `cexp.c' are 438: more recent than `c-parse.y' and `cexp.y' and you do not plan to 439: change the `.y' files.) 1.1 root 440: 1.1.1.3 root 441: Bison versions older than Sept 8, 1988 will produce incorrect 1.1 root 442: output for `c-parse.c'. 443: 1.1.1.5 ! root 444: 7. Build the compiler. Just type `make LANGUAGES=c' in the compiler 1.1 root 445: directory. 446: 1.1.1.3 root 447: `LANGUAGES=c' specifies that only the C compiler should be 1.1 root 448: compiled. The makefile normally builds compilers for all the 449: supported languages; currently, C, C++ and Objective C. However, 450: C is the only language that is sure to work when you build with 451: other non-GNU C compilers. In addition, building anything but C 452: at this stage is a waste of time. 453: 1.1.1.3 root 454: In general, you can specify the languages to build by typing the 455: argument `LANGUAGES="LIST"', where LIST is one or more words from 456: the list `c', `c++', and `objective-c'. 457: 458: Ignore any warnings you may see about "statement not reached" in 1.1.1.5 ! root 459: `insn-emit.c'; they are normal. Also, warnings about "unknown ! 460: escape sequence" are normal in `genopinit.c' and perhaps some ! 461: other files. Any other compilation errors may represent bugs in ! 462: the port to your machine or operating system, and should be ! 463: investigated and reported. 1.1.1.3 root 464: 465: Some commercial compilers fail to compile GNU CC because they have 466: bugs or limitations. For example, the Microsoft compiler is said 467: to run out of macro space. Some Ultrix compilers run out of 1.1 root 468: expression space; then you need to break up the statement where 469: the problem happens. 470: 1.1.1.3 root 471: If you are building with a previous GNU C compiler, do not use 1.1.1.5 ! root 472: `CC=gcc' on the make command or by editing the Makefile. Instead, 1.1.1.3 root 473: use a full pathname to specify the compiler, such as 474: `CC=/usr/local/bin/gcc'. This is because make might execute the 475: `gcc' in the current directory before all of the compiler 476: components have been built. 477: 1.1.1.5 ! root 478: 8. If you are building a cross-compiler, stop here. *Note 1.1.1.3 root 479: Cross-Compiler::. 1.1 root 480: 1.1.1.5 ! root 481: 9. Move the first-stage object files and executables into a 1.1 root 482: subdirectory with this command: 483: 484: make stage1 485: 1.1.1.5 ! root 486: The files are moved into a subdirectory named `stage1'. Once 1.1 root 487: installation is complete, you may wish to delete these files with 488: `rm -r stage1'. 489: 1.1.1.5 ! root 490: 10. If you have chosen a configuration for GNU CC which requires other ! 491: GNU tools (such as GAS or the GNU linker) instead of the standard ! 492: system tools, install the required tools in the `stage1' ! 493: subdirectory under the names `as', `ld' or whatever is ! 494: appropriate. This will enable the stage 1 compiler to find the ! 495: proper tools in the following stage. ! 496: ! 497: Alternatively, you can do subsequent compilation using a value of ! 498: the `PATH' environment variable such that the necessary GNU tools ! 499: come before the standard system tools. ! 500: ! 501: 11. Recompile the compiler with itself, with this command: 1.1 root 502: 1.1.1.4 root 503: make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O" 1.1 root 504: 1.1.1.3 root 505: This is called making the stage 2 compiler. 1.1 root 506: 1.1.1.3 root 507: The command shown above builds compilers for all the supported 1.1 root 508: languages. If you don't want them all, you can specify the 1.1.1.3 root 509: languages to build by typing the argument `LANGUAGES="LIST"'. LIST 510: should contain one or more words from the list `c', `c++', 511: `objective-c', and `proto'. Separate the words with spaces. 512: `proto' stands for the programs `protoize' and `unprotoize'; they 513: are not a separate language, but you use `LANGUAGES' to enable or 514: disable their installation. 515: 516: If you are going to build the stage 3 compiler, then you might 517: want to build only the C language in stage 2. 518: 519: Once you have built the stage 2 compiler, if you are short of disk 520: space, you can delete the subdirectory `stage1'. 521: 522: On a 68000 or 68020 system lacking floating point hardware, unless 523: you have selected a `tm.h' file that expects by default that there 524: is no such hardware, do this instead: 1.1 root 525: 1.1.1.4 root 526: make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O -msoft-float" 1.1 root 527: 1.1.1.5 ! root 528: 12. If you wish to test the compiler by compiling it with itself one ! 529: more time, install any other necessary GNU tools (such as GAS or ! 530: the GNU linker) in the `stage2' subdirectory as you did in the ! 531: `stage1' subdirectory, then do this: 1.1 root 532: 533: make stage2 1.1.1.4 root 534: make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" 1.1 root 535: 536: This is called making the stage 3 compiler. Aside from the `-B' 1.1.1.4 root 537: option, the compiler options should be the same as when you made 538: the stage 2 compiler. But the `LANGUAGES' option need not be the 539: same. The command shown above builds compilers for all the 540: supported languages; if you don't want them all, you can specify 541: the languages to build by typing the argument `LANGUAGES="LIST"', 542: as described above. 1.1 root 543: 1.1.1.3 root 544: Then compare the latest object files with the stage 2 object 545: files--they ought to be identical, unless they contain time stamps. 546: You can compare the files, disregarding the time stamps if any, 547: like this: 548: 549: make compare 550: 551: This will mention any object files that differ between stage 2 and 552: stage 3. Any difference, no matter how innocuous, indicates that 553: the stage 2 compiler has compiled GNU CC incorrectly, and is 1.1 root 554: therefore a potentially serious bug which you should investigate 1.1.1.3 root 555: and report. 1.1 root 556: 1.1.1.3 root 557: If your system does not put time stamps in the object files, then 558: this is a faster way to compare them (using the Bourne shell): 1.1 root 559: 560: for file in *.o; do 1.1.1.3 root 561: cmp $file stage2/$file 1.1 root 562: done 563: 1.1.1.3 root 564: If you have built the compiler with the `-mno-mips-tfile' option on 565: MIPS machines, you will not be able to compare the files. 1.1 root 566: 1.1.1.5 ! root 567: The Alpha stores file names in the object files and `make compare' ! 568: does not know how to ignore them, so normally you cannot compare ! 569: on the Alpha. However, if you use the `-save-temps' option when ! 570: compiling *both* stage 2 and stage 3, this causes the same file ! 571: names to be used in both stages; then you can do the comparison. ! 572: ! 573: 13. Install the compiler driver, the compiler's passes and run-time ! 574: support with `make install'. Use the same value for `CC', ! 575: `CFLAGS' and `LANGUAGES' that you used when compiling the files ! 576: that are being installed. One reason this is necessary is that ! 577: some versions of Make have bugs and recompile files gratuitously ! 578: when you do this step. If you use the same variable values, those ! 579: files will be recompiled properly. 1.1 root 580: 1.1.1.5 ! root 581: For example, if you have built the stage 2 compiler, you can use ! 582: the following command: 1.1 root 583: 1.1.1.5 ! root 584: make install CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" LANGUAGES="LIST" 1.1 root 585: 1.1.1.3 root 586: This copies the files `cc1', `cpp' and `libgcc.a' to files `cc1', 1.1.1.5 ! root 587: `cpp' and `libgcc.a' in the directory 1.1.1.2 root 588: `/usr/local/lib/gcc-lib/TARGET/VERSION', which is where the 589: compiler driver program looks for them. Here TARGET is the target 590: machine type specified when you ran `configure', and VERSION is 591: the version number of GNU CC. This naming scheme permits various 1.1 root 592: versions and/or cross-compilers to coexist. 593: 1.1.1.5 ! root 594: This also copies the driver program `xgcc' into ! 595: `/usr/local/bin/gcc', so that it appears in typical execution ! 596: search paths. ! 597: ! 598: On some systems, this command causes recompilation of some files. ! 599: This is usually due to bugs in `make'. You should either ignore ! 600: this problem, or use GNU Make. 1.1.1.3 root 601: 602: *Warning: there is a bug in `alloca' in the Sun library. To avoid 603: this bug, be sure to install the executables of GNU CC that were 604: compiled by GNU CC. (That is, the executables from stage 2 or 3, 605: not stage 1.) They use `alloca' as a built-in function and never 606: the one in the library.* 1.1.1.2 root 607: 1.1.1.3 root 608: (It is usually better to install GNU CC executables from stage 2 609: or 3, since they usually run faster than the ones compiled with 1.1.1.2 root 610: some other compiler.) 1.1 root 611: 1.1.1.5 ! root 612: 14. Install the Objective C library (if you have built the Objective C 1.1.1.4 root 613: compiler). Here is the command to do this: 614: 615: make install-libobjc CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" 616: 1.1.1.5 ! root 617: 15. If you're going to use C++, it's likely that you need to also ! 618: install the libg++ distribution. It should be available from the ! 619: same place where you got the GNU C distribution. Just as GNU C 1.1.1.4 root 620: does not distribute a C runtime library, it also does not include 621: a C++ run-time library. All I/O functionality, special class 1.1.1.5 ! root 622: libraries, etc., are available in the libg++ distribution. 1.1 root 623: 624: Compilation in a Separate Directory 1.1.1.5 ! root 625: =================================== 1.1 root 626: 627: If you wish to build the object files and executables in a directory 628: other than the one containing the source files, here is what you must 629: do differently: 630: 631: 1. Make sure you have a version of Make that supports the `VPATH' 632: feature. (GNU Make supports it, as do Make versions on most BSD 633: systems.) 634: 1.1.1.3 root 635: 2. If you have ever run `configure' in the source directory, you must 636: undo the configuration. Do this by running: 1.1.1.2 root 637: 1.1.1.3 root 638: make distclean 1.1.1.2 root 639: 640: 3. Go to the directory in which you want to build the compiler before 641: running `configure': 1.1 root 642: 643: mkdir gcc-sun3 644: cd gcc-sun3 645: 1.1.1.3 root 646: On systems that do not support symbolic links, this directory must 647: be on the same file system as the source code directory. 1.1 root 648: 1.1.1.2 root 649: 4. Specify where to find `configure' when you run it: 1.1 root 650: 1.1.1.3 root 651: ../gcc/configure ... 1.1 root 652: 1.1.1.3 root 653: This also tells `configure' where to find the compiler sources; 654: `configure' takes the directory from the file name that was used to 655: invoke it. But if you want to be sure, you can specify the source 656: directory with the `--srcdir' option, like this: 1.1 root 657: 1.1.1.3 root 658: ../gcc/configure --srcdir=../gcc sun3 1.1 root 659: 1.1.1.3 root 660: The directory you specify with `--srcdir' need not be the same as 661: the one that `configure' is found in. 1.1 root 662: 663: Now, you can run `make' in that directory. You need not repeat the 1.1.1.3 root 664: configuration steps shown above, when ordinary source files change. You 665: must, however, run `configure' again when the configuration files 1.1 root 666: change, if your system does not support symbolic links. 667: 1.1.1.3 root 668: Building and Installing a Cross-Compiler 1.1.1.5 ! root 669: ======================================== 1.1.1.3 root 670: 671: GNU CC can function as a cross-compiler for many machines, but not 672: all. 673: 1.1.1.5 ! root 674: * Cross-compilers for the Mips as target currently do not work ! 675: because the auxiliary programs `mips-tdump.c' and `mips-tfile.c' ! 676: can't be compiled on anything but a Mips. 1.1.1.3 root 677: 678: * Cross-compilers to or from the Vax probably don't work completely 679: because the Vax uses an incompatible floating point format (not 680: IEEE format). 681: 682: Since GNU CC generates assembler code, you probably need a 683: cross-assembler that GNU CC can run, in order to produce object files. 684: If you want to link on other than the target machine, you need a 685: cross-linker as well. You also need header files and libraries suitable 686: for the target machine that you can install on the host machine. 687: 688: To build GNU CC as a cross-compiler, you start out by running 1.1.1.4 root 689: `configure'. You must specify two different configurations, the host 1.1.1.3 root 690: and the target. Use the `--host=HOST' option for the host and 691: `--target=TARGET' to specify the target type. For example, here is how 692: to configure for a cross-compiler that runs on a hypothetical Intel 386 693: system and produces code for an HP 68030 system running BSD: 694: 695: configure --target=m68k-hp-bsd4.3 --host=i386-bozotheclone-bsd4.3 696: 697: Next you should install the cross-assembler and cross-linker (and 1.1.1.4 root 698: `ar' and `ranlib'). Put them in the directory `/usr/local/TARGET/bin'. 1.1.1.5 ! root 699: The installation of GNU CC will find them there and copy or link them 1.1.1.3 root 700: to the proper place to find them when you run the cross-compiler later. 701: 702: If you want to install any additional libraries to use with the 703: cross-compiler, put them in the directory `/usr/local/TARGET/lib'; all 704: files in that subdirectory will be installed in the proper place when 1.1.1.5 ! root 705: you install the cross-compiler. Likewise, put the header files for the 1.1.1.3 root 706: target machine in `/usr/local/TARGET/include'. 707: 1.1.1.4 root 708: You must now produce a substitute for `libgcc1.a'. Normally this 709: file is compiled with the "native compiler" for the target machine; 710: compiling it with GNU CC does not work. But compiling it with the host 711: machine's compiler also doesn't work--that produces a file that would 712: run on the host, and you need it to run on the target. 1.1.1.3 root 713: 714: We can't give you any automatic way to produce this substitute. For 1.1.1.5 ! root 715: some targets, the subroutines in `libgcc1.c' are not actually used. ! 716: You need not provide the ones that won't be used. The ones that most 1.1.1.3 root 717: commonly are used are the multiplication, division and remainder 718: routines--many RISC machines rely on the library for this. One way to 719: make them work is to define the appropriate `perform_...' macros for 720: the subroutines that you need. If these definitions do not use the C 721: arithmetic operators that they are meant to implement, you might be 1.1.1.5 ! root 722: able to compile them with the cross-compiler you are building. To do 1.1.1.4 root 723: this, specify `LIBGCC1=libgcc1.a OLDCC=./xgcc' when building the 724: compiler. 725: 726: Now you can proceed just as for compiling a single-machine compiler 727: through the step of building stage 1. If you have not provided some 728: sort of `libgcc1.a', then compilation will give up at the point where 729: it needs that file, printing a suitable error message. If you do 730: provide `libgcc1.a', then building the compiler will automatically 731: compile and link a test program called `cross-test'; if you get errors 732: in the linking, it means that not all of the necessary routines in 733: `libgcc1.a' are available. 734: 735: When you are using a cross-compiler configuration, building stage 1 736: does not compile all of GNU CC. This is because one part of building, 737: the compilation of `libgcc2.c', requires use of the cross-compiler. 738: 739: However, when you type `make install' to install the bulk of the 740: cross-compiler, that will also compile `libgcc2.c' and install the 741: resulting `libgcc.a'. 1.1.1.3 root 742: 743: Do not try to build stage 2 for a cross-compiler. It doesn't work to 744: rebuild GNU CC as a cross-compiler using the cross-compiler, because 745: that would produce a program that runs on the target machine, not on the 746: host. For example, if you compile a 386-to-68030 cross-compiler with 747: itself, the result will not be right either for the 386 (because it was 748: compiled into 68030 code) or for the 68030 (because it was configured 749: for a 386 as the host). If you want to compile GNU CC into 68030 code, 750: whether you compile it on a 68030 or with a cross-compiler on a 386, you 751: must specify a 68030 as the host when you configure it. 752: 1.1.1.5 ! root 753: Installing on the HP Precision Architecture ! 754: =========================================== 1.1.1.3 root 755: 756: There are two variants of this CPU, called 1.0 and 1.1, which have 757: different machine descriptions. You must use the right one for your 758: machine. All 7NN machines and 8N7 machines use 1.1, while all other 759: 8NN machines use 1.0. 760: 761: The easiest way to handle this problem is to use `configure hpNNN' 762: or `configure hpNNN-hpux', where NNN is the model number of the 763: machine. Then `configure' will figure out if the machine is a 1.0 or 764: 1.1. Use `uname -a' to find out the model number of your machine. 765: 766: `-g' does not work on HP-UX, since that system uses a peculiar 1.1.1.4 root 767: debugging format which GNU CC does not know about. There are 768: preliminary versions of GAS and GDB for the HP-PA which do work with 769: GNU CC for debugging. You can get them by anonymous ftp from 770: `jaguar.cs.utah.edu' `dist' subdirectory. You would need to install 771: GAS in the file 1.1.1.3 root 772: 773: /usr/local/lib/gcc-lib/CONFIGURATION/GCCVERSION/as 774: 775: where CONFIGURATION is the configuration name (perhaps `hpNNN-hpux') 1.1.1.4 root 776: and GCCVERSION is the GNU CC version number. Do this *before* starting 777: the build process, otherwise you will get errors from the HPUX 778: assembler while building `libgcc2.a'. The command 1.1.1.3 root 779: 1.1.1.4 root 780: make install-dir 1.1.1.3 root 781: 1.1.1.4 root 782: will create the necessary directory hierarchy so you can install GAS 783: before building GCC. 1.1.1.3 root 784: 1.1.1.4 root 785: If you obtained GAS before October 6, 1992 it is highly recommended 786: you get a new one to avoid several bugs which have been discovered 787: recently. 788: 789: To enable debugging, configure GNU CC with the `--gas' option before 790: building. 1.1.1.3 root 791: 1.1.1.5 ! root 792: It has been reported that GNU CC produces invalid assembly code for ! 793: 1.1 machines running HP-UX 8.02 when using the HP assembler. Typically ! 794: the errors look like this: ! 795: as: bug.s @line#15 [err#1060] ! 796: Argument 0 or 2 in FARG upper ! 797: - lookahead = ARGW1=FR,RTNVAL=GR ! 798: as: foo.s @line#28 [err#1060] ! 799: Argument 0 or 2 in FARG upper ! 800: - lookahead = ARGW1=FR ! 801: ! 802: You can check the version of HP-UX you are running by executing the ! 803: command `uname -r'. If you are indeed running HP-UX 8.02 on a 1.1 ! 804: machine and using the HP assembler then configure GCC with ! 805: "hp700-hpux8.02". 1.1.1.3 root 806: 1.1 root 807: Installing GNU CC on the Sun 1.1.1.5 ! root 808: ============================ ! 809: ! 810: On Solaris (version 2.1), do not use the linker or other tools in ! 811: `/usr/ucb' to build GNU CC. Use `/usr/ccs/bin'. 1.1 root 812: 813: Make sure the environment variable `FLOAT_OPTION' is not set when 814: you compile `libgcc.a'. If this option were set to `f68881' when 815: `libgcc.a' is compiled, the resulting code would demand to be linked 1.1.1.3 root 816: with a special startup file and would not link properly without special 817: pains. 1.1 root 818: 1.1.1.3 root 819: There is a bug in `alloca' in certain versions of the Sun library. 1.1 root 820: To avoid this bug, install the binaries of GNU CC that were compiled by 821: GNU CC. They use `alloca' as a built-in function and never the one in 822: the library. 823: 824: Some versions of the Sun compiler crash when compiling GNU CC. The 1.1.1.3 root 825: problem is a segmentation fault in cpp. This problem seems to be due to 826: the bulk of data in the environment variables. You may be able to avoid 827: it by using the following command to compile GNU CC with Sun CC: 1.1 root 828: 829: make CC="TERMCAP=x OBJS=x LIBFUNCS=x STAGESTUFF=x cc" 830: 831: Installing GNU CC on the 3b1 1.1.1.5 ! root 832: ============================ 1.1 root 833: 834: Installing GNU CC on the 3b1 is difficult if you do not already have 835: GNU CC running, due to bugs in the installed C compiler. However, the 836: following procedure might work. We are unable to test it. 837: 838: 1. Comment out the `#include "config.h"' line on line 37 of `cccp.c' 839: and do `make cpp'. This makes a preliminary version of GNU cpp. 840: 841: 2. Save the old `/lib/cpp' and copy the preliminary GNU cpp to that 842: file name. 843: 844: 3. Undo your change in `cccp.c', or reinstall the original version, 845: and do `make cpp' again. 846: 847: 4. Copy this final version of GNU cpp into `/lib/cpp'. 848: 849: 5. Replace every occurrence of `obstack_free' in the file `tree.c' 850: with `_obstack_free'. 851: 852: 6. Run `make' to get the first-stage GNU CC. 853: 854: 7. Reinstall the original version of `/lib/cpp'. 855: 1.1.1.3 root 856: 8. Now you can compile GNU CC with itself and install it in the normal 857: fashion. 1.1 root 858: 859: Installing GNU CC on Unos 1.1.1.5 ! root 860: ========================= 1.1 root 861: 862: Use `configure unos' for building on Unos. 863: 864: The Unos assembler is named `casm' instead of `as'. For some 865: strange reason linking `/bin/as' to `/bin/casm' changes the behavior, 866: and does not work. So, when installing GNU CC, you should install the 867: following script as `as' in the subdirectory where the passes of GCC 868: are installed: 869: 870: #!/bin/sh 871: casm $* 872: 1.1.1.5 ! root 873: The default Unos library is named `libunos.a' instead of `libc.a'. 1.1 root 874: To allow GNU CC to function, either change all references to `-lc' in 875: `gcc.c' to `-lunos' or link `/lib/libc.a' to `/lib/libunos.a'. 876: 1.1.1.3 root 877: When compiling GNU CC with the standard compiler, to overcome bugs in 1.1.1.5 ! root 878: the support of `alloca', do not use `-O' when making stage 2. Then use 1.1.1.3 root 879: the stage 2 compiler with `-O' to make the stage 3 compiler. This 1.1 root 880: compiler will have the same characteristics as the usual stage 2 881: compiler on other systems. Use it to make a stage 4 compiler and 882: compare that with stage 3 to verify proper compilation. 883: 1.1.1.3 root 884: (Perhaps simply defining `ALLOCA' in `x-crds' as described in the 885: comments there will make the above paragraph superfluous. Please 886: inform us of whether this works.) 887: 1.1 root 888: Unos uses memory segmentation instead of demand paging, so you will 889: need a lot of memory. 5 Mb is barely enough if no other tasks are 1.1.1.5 ! root 890: running. If linking `cc1' fails, try putting the object files into a 1.1 root 891: library and linking from that library. 892: 893: Installing GNU CC on VMS 1.1.1.5 ! root 894: ======================== 1.1 root 895: 896: The VMS version of GNU CC is distributed in a backup saveset 897: containing both source code and precompiled binaries. 898: 899: To install the `gcc' command so you can use the compiler easily, in 1.1.1.3 root 900: the same manner as you use the VMS C compiler, you must install the VMS 901: CLD file for GNU CC as follows: 1.1 root 902: 903: 1. Define the VMS logical names `GNU_CC' and `GNU_CC_INCLUDE' to 1.1.1.4 root 904: point to the directories where the GNU CC executables 905: (`gcc-cpp.exe', `gcc-cc1.exe', etc.) and the C include files are 906: kept respectively. This should be done with the commands: 1.1 root 907: 1.1.1.2 root 908: $ assign /system /translation=concealed - 909: disk:[gcc.] gnu_cc 910: $ assign /system /translation=concealed - 911: disk:[gcc.include.] gnu_cc_include 1.1 root 912: 1.1.1.3 root 913: with the appropriate disk and directory names. These commands can 914: be placed in your system startup file so they will be executed 915: whenever the machine is rebooted. You may, if you choose, do this 916: via the `GCC_INSTALL.COM' script in the `[GCC]' directory. 1.1 root 917: 918: 2. Install the `GCC' command with the command line: 919: 1.1.1.2 root 920: $ set command /table=sys$common:[syslib]dcltables - 921: /output=sys$common:[syslib]dcltables gnu_cc:[000000]gcc 922: $ install replace sys$common:[syslib]dcltables 1.1 root 923: 924: 3. To install the help file, do the following: 925: 1.1.1.4 root 926: $ library/help sys$library:helplib.hlb gcc.hlp 1.1 root 927: 928: Now you can invoke the compiler with a command like `gcc /verbose 929: file.c', which is equivalent to the command `gcc -v -c file.c' in 930: Unix. 931: 932: If you wish to use GNU C++ you must first install GNU CC, and then 933: perform the following steps: 934: 935: 1. Define the VMS logical name `GNU_GXX_INCLUDE' to point to the 936: directory where the preprocessor will search for the C++ header 1.1.1.5 ! root 937: files. This can be done with the command: 1.1 root 938: 1.1.1.2 root 939: $ assign /system /translation=concealed - 940: disk:[gcc.gxx_include.] gnu_gxx_include 1.1 root 941: 1.1.1.3 root 942: with the appropriate disk and directory name. If you are going to 943: be using libg++, this is where the libg++ install procedure will 944: install the libg++ header files. 1.1 root 945: 946: 2. Obtain the file `gcc-cc1plus.exe', and place this in the same 947: directory that `gcc-cc1.exe' is kept. 948: 1.1.1.3 root 949: The GNU C++ compiler can be invoked with a command like `gcc /plus 950: /verbose file.cc', which is equivalent to the command `g++ -v -c 951: file.cc' in Unix. 1.1 root 952: 953: We try to put corresponding binaries and sources on the VMS 954: distribution tape. But sometimes the binaries will be from an older 1.1.1.4 root 955: version than the sources, because we don't always have time to update 1.1 root 956: them. (Use the `/version' option to determine the version number of 957: the binaries and compare it with the source file `version.c' to tell 1.1.1.3 root 958: whether this is so.) In this case, you should use the binaries you get 959: to recompile the sources. If you must recompile, here is how: 1.1 root 960: 1.1.1.5 ! root 961: 1. Execute the command procedure `vmsconfig.com' to set up the files ! 962: `tm.h', `config.h', `aux-output.c', and `md.', and to create files ! 963: `tconfig.h' and `hconfig.h'. This procedure also creates several ! 964: linker option files used by `make-cc1.com' and a data file used by ! 965: `make-l2.com'. 1.1.1.4 root 966: 967: $ @vmsconfig.com 1.1 root 968: 969: 2. Setup the logical names and command tables as defined above. In 970: addition, define the VMS logical name `GNU_BISON' to point at the 971: to the directories where the Bison executable is kept. This 972: should be done with the command: 973: 1.1.1.2 root 974: $ assign /system /translation=concealed - 975: disk:[bison.] gnu_bison 1.1 root 976: 1.1.1.3 root 977: You may, if you choose, use the `INSTALL_BISON.COM' script in the 978: `[BISON]' directory. 1.1 root 979: 980: 3. Install the `BISON' command with the command line: 981: 1.1.1.2 root 982: $ set command /table=sys$common:[syslib]dcltables - 983: /output=sys$common:[syslib]dcltables - 984: gnu_bison:[000000]bison 985: $ install replace sys$common:[syslib]dcltables 1.1 root 986: 1.1.1.5 ! root 987: 4. Type `@make-gcc' to recompile everything (alternatively, submit ! 988: the file `make-gcc.com' to a batch queue). If you wish to build ! 989: the GNU C++ compiler as well as the GNU CC compiler, you must 1.1.1.3 root 990: first edit `make-gcc.com' and follow the instructions that appear 991: in the comments. 1.1 root 992: 1.1.1.2 root 993: 5. In order to use GCC, you need a library of functions which GCC 994: compiled code will call to perform certain tasks, and these 995: functions are defined in the file `libgcc2.c'. To compile this 996: you should use the command procedure `make-l2.com', which will 1.1.1.5 ! root 997: generate the library `libgcc2.olb'. `libgcc2.olb' should be built 1.1.1.3 root 998: using the compiler built from the same distribution that 1.1.1.2 root 999: `libgcc2.c' came from, and `make-gcc.com' will automatically do 1000: all of this for you. 1001: 1.1.1.3 root 1002: To install the library, use the following commands: 1.1.1.2 root 1003: 1.1.1.4 root 1004: $ library gnu_cc:[000000]gcclib/delete=(new,eprintf) 1.1.1.5 ! root 1005: $ library gnu_cc:[000000]gcclib/delete=L_* 1.1.1.4 root 1006: $ library libgcc2/extract=*/output=libgcc2.obj 1007: $ library gnu_cc:[000000]gcclib libgcc2.obj 1.1.1.2 root 1008: 1.1.1.3 root 1009: The first command simply removes old modules that will be replaced 1.1.1.5 ! root 1010: with modules from `libgcc2' under different module names. The ! 1011: modules `new' and `eprintf' may not actually be present in your ! 1012: `gcclib.olb'--if the VMS librarian complains about those modules ! 1013: not being present, simply ignore the message and continue on with ! 1014: the next command. The second command removes the modules that ! 1015: came from the previous version of the library `libgcc2.c'. 1.1.1.3 root 1016: 1017: Whenever you update the compiler on your system, you should also 1018: update the library with the above procedure. 1019: 1.1.1.4 root 1020: 6. You may wish to build GCC in such a way that no files are written 1.1.1.3 root 1021: to the directory where the source files reside. An example would 1022: be the when the source files are on a read-only disk. In these 1023: cases, execute the following DCL commands (substituting your 1024: actual path names): 1025: 1.1.1.4 root 1026: $ assign dua0:[gcc.build_dir.]/translation=concealed, - 1027: dua1:[gcc.source_dir.]/translation=concealed gcc_build 1.1.1.3 root 1028: $ set default gcc_build:[000000] 1029: 1.1.1.5 ! root 1030: where the directory `dua1:[gcc.source_dir]' contains the source ! 1031: code, and the directory `dua0:[gcc.build_dir]' is meant to contain ! 1032: all of the generated object files and executables. Once you have ! 1033: done this, you can proceed building GCC as described above. (Keep ! 1034: in mind that `gcc_build' is a rooted logical name, and thus the ! 1035: device names in each element of the search list must be an actual ! 1036: physical device name rather than another rooted logical name). 1.1.1.3 root 1037: 1.1.1.4 root 1038: 7. *If you are building GNU CC with a previous version of GNU CC, you 1.1.1.3 root 1039: also should check to see that you have the newest version of the 1040: assembler*. In particular, GNU CC version 2 treats global constant 1041: variables slightly differently from GNU CC version 1, and GAS 1042: version 1.38.1 does not have the patches required to work with GCC 1.1.1.5 ! root 1043: version 2. If you use GAS 1.38.1, then `extern const' variables 1.1.1.3 root 1044: will not have the read-only bit set, and the linker will generate 1045: warning messages about mismatched psect attributes for these 1046: variables. These warning messages are merely a nuisance, and can 1047: safely be ignored. 1.1 root 1048: 1.1.1.3 root 1049: If you are compiling with a version of GNU CC older than 1.33, 1.1 root 1050: specify `/DEFINE=("inline=")' as an option in all the 1051: compilations. This requires editing all the `gcc' commands in 1.1.1.5 ! root 1052: `make-cc1.com'. (The older versions had problems supporting 1.1 root 1053: `inline'.) Once you have a working 1.33 or newer GNU CC, you can 1054: change this file back. 1055: 1.1.1.4 root 1056: 8. If you want to build GNU CC with the VAX C compiler, you will need 1057: to make minor changes in `make-cccp.com' and `make-cc1.com' to 1058: choose alternate definitions of `CC', `CFLAGS', and `LIBS'. See 1059: comments in those files. However, you must also have a working 1060: version of the GNU assembler (GNU as, aka GAS) as it is used as 1061: the back-end for GNU CC to produce binary object modules and is 1062: not included in the GNU CC sources. GAS is also needed to compile 1063: `libgcc2' in order to build `gcclib' (see above); `make-l2.com' 1064: expects to be able to find it operational in 1065: `gnu_cc:[000000]gnu-as.exe'. 1066: 1067: To use GNU CC on VMS, you need the VMS driver programs `gcc.exe', 1068: `gcc.com', and `gcc.cld'. They are distributed with the VMS 1069: binaries (`gcc-vms') rather than the GNU CC sources. GAS is also 1070: included in `gcc-vms', as is Bison. 1071: 1072: Once you have successfully built GNU CC with VAX C, you should use 1073: the resulting compiler to rebuild itself. Before doing this, be 1074: sure to restore the `CC', `CFLAGS', and `LIBS' definitions in 1075: `make-cccp.com' and `make-cc1.com'. The second generation 1076: compiler will be able to take advantage of many optimizations that 1077: must be suppressed when building with other compilers. 1078: 1.1 root 1079: Under previous versions of GNU CC, the generated code would 1.1.1.4 root 1080: occasionally give strange results when linked with the sharable 1.1.1.5 ! root 1081: `VAXCRTL' library. Now this should work. 1.1 root 1082: 1083: Even with this version, however, GNU CC itself should not be linked 1.1.1.4 root 1084: with the sharable `VAXCRTL'. The version of `qsort' in `VAXCRTL' has a 1085: bug (known to be present in VMS versions V4.6 through V5.5) which 1086: causes the compiler to fail. 1.1 root 1087: 1.1.1.5 ! root 1088: The executables are generated by `make-cc1.com' and `make-cccp.com' ! 1089: use the object library version of `VAXCRTL' in order to make use of the ! 1090: `qsort' routine in `gcclib.olb'. If you wish to link the compiler ! 1091: executables with the shareable image version of `VAXCRTL', you should ! 1092: edit the file `tm.h' (created by `vmsconfig.com') to define the macro ! 1093: `QSORT_WORKAROUND'. 1.1.1.4 root 1094: 1095: `QSORT_WORKAROUND' is always defined when GNU CC is compiled with 1096: VAX C, to avoid a problem in case `gcclib.olb' is not yet available. 1097: 1098: Installing GNU CC on the WE32K 1.1.1.5 ! root 1099: ============================== 1.1.1.4 root 1100: 1101: These computers are also known as the 3b2, 3b5, 3b20 and other 1102: similar names. (However, the 3b1 is actually a 68000; see *Note 3b1 1103: Install::.) 1104: 1105: Don't use `-g' when compiling with the system's compiler. The 1106: system's linker seems to be unable to handle such a large program with 1107: debugging information. 1108: 1109: The system's compiler runs out of capacity when compiling `stmt.c' 1110: in GNU CC. You can work around this by building `cpp' in GNU CC first, 1111: then use that instead of the system's preprocessor with the system's C 1112: compiler to compile `stmt.c'. Here is how: 1113: 1114: mv /lib/cpp /lib/cpp.att 1115: cp cpp /lib/cpp.gnu 1116: echo "/lib/cpp.gnu -traditional $*" > /lib/cpp 1117: chmod +x /lib/cpp 1118: 1119: The system's compiler produces bad code for some of the GNU CC 1120: optimization files. So you must build the stage 2 compiler without 1.1.1.5 ! root 1121: optimization. Then build a stage 3 compiler with optimization. That 1.1.1.4 root 1122: executable should work. Here are the necessary commands: 1123: 1124: make LANGUAGES=c CC=stage1/xgcc CFLAGS="-Bstage1/ -g" 1125: make stage2 1126: make CC=stage2/xgcc CFLAGS="-Bstage2/ -g -O" 1127: 1128: You may need to raise the ULIMIT setting to build a C++ compiler, as 1129: the file `cc1plus' is larger than one megabyte. 1130: 1131: Installing GNU CC on the MIPS 1.1.1.5 ! root 1132: ============================= 1.1.1.4 root 1133: 1.1.1.5 ! root 1134: See *Note Installation:: about whether to use either of the options ! 1135: `--with-stabs' or `--with-gnu-as'. 1.1.1.4 root 1136: 1137: The MIPS C compiler needs to be told to increase its table size for 1138: switch statements with the `-Wf,-XNg1500' option in order to compile 1139: `cp-parse.c'. If you use the `-O2' optimization option, you also need 1.1.1.5 ! root 1140: to use `-Olimit 3000'. Both of these options are automatically 1.1.1.4 root 1141: generated in the `Makefile' that the shell script `configure' builds. 1142: If you override the `CC' make variable and use the MIPS compilers, you 1143: may need to add `-Wf,-XNg1500 -Olimit 3000'. 1144: 1145: MIPS computers running RISC-OS can support four different 1146: personalities: default, BSD 4.3, System V.3, and System V.4 (older 1147: versions of RISC-OS don't support V.4). To configure GCC for these 1148: platforms use the following configurations: 1149: 1150: `mips-mips-riscos`rev'' 1151: Default configuration for RISC-OS, revision `rev'. 1152: 1153: `mips-mips-riscos`rev'bsd' 1154: BSD 4.3 configuration for RISC-OS, revision `rev'. 1155: 1156: `mips-mips-riscos`rev'sysv4' 1157: System V.4 configuration for RISC-OS, revision `rev'. 1158: 1159: `mips-mips-riscos`rev'sysv' 1160: System V.3 configuration for RISC-OS, revision `rev'. 1161: 1162: The revision `rev' mentioned above is the revision of RISC-OS to 1163: use. You must reconfigure GCC when going from a RISC-OS revision 4 to 1164: RISC-OS revision 5. This has the effect of avoiding a linker bug. 1165: 1166: DECstations can support three different personalities: Ultrix, DEC 1167: OSF/1, and OSF/rose. To configure GCC for these platforms use the 1168: following configurations: 1169: 1170: `decstation-ultrix' 1171: Ultrix configuration. 1172: 1173: `decstation-osf1' 1174: Dec's version of OSF/1. 1175: 1176: `decstation-osfrose' 1177: Open Software Foundation reference port of OSF/1 which uses the 1178: OSF/rose object file format instead of ECOFF. Normally, you would 1179: not select this configuration. 1.1.1.2 root 1180: 1.1.1.5 ! root 1181: On Irix version 4.0.5F, and perhaps on some other versions as well, ! 1182: there is an assembler bug that reorders instructions incorrectly. To ! 1183: work around it, specify the target configuration `mips-sgi-irix4loser'. ! 1184: This configuration inhibits assembler optimization. ! 1185: ! 1186: You can turn off assembler optimization in a compiler configured with ! 1187: target `mips-sgi-irix4' using the `-noasmopt' option. This compiler ! 1188: option passes the option `-O0' to the assembler, to inhibit reordering. ! 1189: ! 1190: The `-noasmopt' option can be useful for testing whether a problem ! 1191: is due to erroneous assembler reordering. Even if a problem does not go ! 1192: away with `-noasmopt', it may still be due to assembler ! 1193: reordering--perhaps GNU CC itself was miscompiled as a result. ! 1194: ! 1195: We know this is inconvenient, but it's the best that can be done at ! 1196: the last minute. ! 1197: ! 1198: `collect2' ! 1199: ========== ! 1200: ! 1201: Many target systems do not have support in the assembler and linker ! 1202: for "constructors"--initialization functions to be called before the ! 1203: official "start" of `main'. On such systems, GNU CC uses a utility ! 1204: called `collect2' to arrange to call these functions at start time. ! 1205: ! 1206: The program `collect2' works by linking the program once and looking ! 1207: through the linker output file for symbols with particular names ! 1208: indicating they are constructor functions. If it finds any, it creates ! 1209: a new temporary `.c' file containing a table of them, compiles it, and ! 1210: links the program a second time including that file. ! 1211: ! 1212: The actual calls to the constructors are carried out by a subroutine ! 1213: called `__main', which is called (automatically) at the beginning of ! 1214: the body of `main' (provided `main' was compiled with GNU CC). ! 1215: ! 1216: The program `collect2' is installed as `ld' in the directory where ! 1217: the passes of the compiler are installed. When `collect2' needs to ! 1218: find the *real* `ld', it tries the following file names: ! 1219: ! 1220: * `gld' in the directories listed in the compiler's search ! 1221: directories. ! 1222: ! 1223: * `gld' in the directories listed in the environment variable `PATH'. ! 1224: ! 1225: * `real-ld' in the compiler's search directories. ! 1226: ! 1227: * `real-ld' in `PATH'. ! 1228: ! 1229: * `ld' in `PATH'. ! 1230: ! 1231: "The compiler's search directories" means all the directories where ! 1232: `gcc' searches for passes of the compiler. This includes directories ! 1233: that you specify with `-B'. ! 1234: ! 1235: Cross compilers search a little differently: ! 1236: ! 1237: * `gld' in the compiler's search directories. ! 1238: ! 1239: * `TARGET-gld' in `PATH'. ! 1240: ! 1241: * `real-ld' in the compiler's search directories. ! 1242: ! 1243: * `TARGET-real-ld' in `PATH'. ! 1244: ! 1245: * `TARGET-ld' in `PATH'. ! 1246: ! 1247: `collect2' does not search for `ld' using the compiler's search ! 1248: directories, because if it did, it would find itself--not the real ! 1249: `ld'--and this could lead to infinite recursion. However, the ! 1250: directory where `collect2' is installed might happen to be in `PATH'. ! 1251: That could lead `collect2' to invoke itself anyway. when looking for ! 1252: `ld'. ! 1253: ! 1254: To prevent this, `collect2' explicitly avoids running `ld' using the ! 1255: file name under which `collect2' itself was invoked. In fact, it ! 1256: remembers up to two such names--in case one copy of `collect2' finds ! 1257: another copy (or version) of `collect2' installed as `ld' in a second ! 1258: place in the search path. ! 1259: ! 1260: If two file names to avoid are not sufficient, you may still ! 1261: encounter an infinite recursion of `collect2' processes. When this ! 1262: happens. check all the files installed as `ld' in any of the ! 1263: directories searched, and straighten out the situation. ! 1264: ! 1265: (In a future version, we will probably change `collect2' to avoid ! 1266: any reinvocation of a file from which any parent `collect2' was run.) ! 1267:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.