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