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