![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-6 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-6 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.7 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.55 from the input 1.1 root 2: file gcc.texi. 3: 4: This file documents the use and the internals of the GNU compiler. 5: 1.1.1.5 root 6: Published by the Free Software Foundation 675 Massachusetts Avenue 7: Cambridge, MA 02139 USA 8: 1.1.1.7 ! root 9: Copyright (C) 1988, 1989, 1992, 1993, 1994 Free Software Foundation, ! 10: Inc. 1.1 root 11: 1.1.1.3 root 12: Permission is granted to make and distribute verbatim copies of this 13: manual provided the copyright notice and this permission notice are 14: preserved on all copies. 1.1 root 15: 16: Permission is granted to copy and distribute modified versions of 17: this manual under the conditions for verbatim copying, provided also 1.1.1.7 ! root 18: that the sections entitled "GNU General Public License," "Funding for ! 19: Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are ! 20: included exactly as in the original, and provided that the entire ! 21: resulting derived work is distributed under the terms of a permission ! 22: notice identical to this one. 1.1 root 23: 24: Permission is granted to copy and distribute translations of this 25: manual into another language, under the above conditions for modified 1.1.1.3 root 26: versions, except that the sections entitled "GNU General Public 1.1.1.7 ! root 27: License," "Funding for Free Software," and "Protect Your Freedom--Fight ! 28: `Look And Feel'", and this permission notice, may be included in ! 29: translations approved by the Free Software Foundation instead of in the ! 30: original English. ! 31: ! 32: ! 33: File: gcc.info, Node: Configurations, Next: Other Dir, Up: Installation ! 34: ! 35: Configurations Supported by GNU CC ! 36: ================================== ! 37: ! 38: Here are the possible CPU types: ! 39: ! 40: 1750a, a29k, alpha, arm, cN, clipper, dsp16xx, elxsi, h8300, ! 41: hppa1.0, hppa1.1, i370, i386, i486, i860, i960, m68000, m68k, m88k, ! 42: mips, ns32k, powerpc, pyramid, romp, rs6000, sh, sparc, sparclite, ! 43: sparc64, vax, we32k. ! 44: ! 45: Here are the recognized company names. As you can see, customary ! 46: abbreviations are used rather than the longer official names. ! 47: ! 48: acorn, alliant, altos, apollo, att, bull, cbm, convergent, convex, ! 49: crds, dec, dg, dolphin, elxsi, encore, harris, hitachi, hp, ibm, ! 50: intergraph, isi, mips, motorola, ncr, next, ns, omron, plexus, ! 51: sequent, sgi, sony, sun, tti, unicom. ! 52: ! 53: The company name is meaningful only to disambiguate when the rest of ! 54: the information supplied is insufficient. You can omit it, writing ! 55: just `CPU-SYSTEM', if it is not needed. For example, `vax-ultrix4.2' ! 56: is equivalent to `vax-dec-ultrix4.2'. ! 57: ! 58: Here is a list of system types: ! 59: ! 60: 386bsd, aix, acis, amigados, aos, aout, bosx, bsd, clix, ctix, ! 61: cxux, dgux, dynix, ebmon, elf, esix, freebsd, hms, genix, gnu, ! 62: gnu/linux, hiux, hpux, iris, irix, isc, luna, lynxos, mach, minix, ! 63: msdos, mvs, netbsd, newsos, nindy, ns, osf, osfrose, ptx, riscix, ! 64: riscos, rtu, sco, solaris, sunos, sym, sysv, ultrix, unicos, ! 65: uniplus, unos, vms, vxworks, xenix. ! 66: ! 67: You can omit the system type; then `configure' guesses the operating ! 68: system from the CPU and company. ! 69: ! 70: You can add a version number to the system type; this may or may not ! 71: make a difference. For example, you can write `bsd4.3' or `bsd4.4' to ! 72: distinguish versions of BSD. In practice, the version number is most ! 73: needed for `sysv3' and `sysv4', which are often treated differently. ! 74: ! 75: If you specify an impossible combination such as `i860-dg-vms', then ! 76: you may get an error message from `configure', or it may ignore part of ! 77: the information and do the best it can with the rest. `configure' ! 78: always prints the canonical name for the alternative that it used. GNU ! 79: CC does not support all possible alternatives. ! 80: ! 81: Often a particular model of machine has a name. Many machine names ! 82: are recognized as aliases for CPU/company combinations. Thus, the ! 83: machine name `sun3', mentioned above, is an alias for `m68k-sun'. ! 84: Sometimes we accept a company name as a machine name, when the name is ! 85: popularly used for a particular machine. Here is a table of the known ! 86: machine names: ! 87: ! 88: 3300, 3b1, 3bN, 7300, altos3068, altos, apollo68, att-7300, ! 89: balance, convex-cN, crds, decstation-3100, decstation, delta, ! 90: encore, fx2800, gmicro, hp7NN, hp8NN, hp9k2NN, hp9k3NN, hp9k7NN, ! 91: hp9k8NN, iris4d, iris, isi68, m3230, magnum, merlin, miniframe, ! 92: mmax, news-3600, news800, news, next, pbd, pc532, pmax, powerpc, ! 93: ps2, risc-news, rtpc, sun2, sun386i, sun386, sun3, sun4, symmetry, ! 94: tower-32, tower. ! 95: ! 96: Remember that a machine name specifies both the cpu type and the company ! 97: name. If you want to install your own homemade configuration files, ! 98: you can use `local' as the company name to access them. If you use ! 99: configuration `CPU-local', the configuration name without the cpu prefix ! 100: is used to form the configuration file names. ! 101: ! 102: Thus, if you specify `m68k-local', configuration uses files ! 103: `m68k.md', `local.h', `m68k.c', `xm-local.h', `t-local', and `x-local', ! 104: all in the directory `config/m68k'. ! 105: ! 106: Here is a list of configurations that have special treatment or ! 107: special things you must know: ! 108: ! 109: `1750a-*-*' ! 110: MIL-STD-1750A processors. ! 111: ! 112: Starting with GCC 2.6.1, the MIL-STD-1750A cross configuration no ! 113: longer supports the Tektronix Assembler, but instead produces ! 114: output for `as1750', an assembler/linker available under the GNU ! 115: Public License for the 1750A. Contact *[email protected]* ! 116: for more details on obtaining `as1750'. A similarly licensed ! 117: simulator for the 1750A is available from same address. ! 118: ! 119: You should ignore a fatal error during the building of libgcc ! 120: (libgcc is not yet implemented for the 1750A.) ! 121: ! 122: The `as1750' assembler requires the file `ms1750.inc', which is ! 123: found in the directory `config/1750a'. ! 124: ! 125: GNU CC produced the same sections as the Fairchild F9450 C ! 126: Compiler, namely: ! 127: ! 128: `NREL' ! 129: The program code section. ! 130: ! 131: `SREL' ! 132: The read/write (RAM) data section. ! 133: ! 134: `KREL' ! 135: The read-only (ROM) constants section. ! 136: ! 137: `IREL' ! 138: Initialization section (code to copy KREL to SREL). ! 139: ! 140: The smallest addressable unit is 16 bits (BITS_PER_UNIT is 16). ! 141: This means that type `char' is represented with a 16-bit word per ! 142: character. The 1750A's "Load/Store Upper/Lower Byte" instructions ! 143: are not used by GNU CC. ! 144: ! 145: There is a problem with long argument lists to functions. The ! 146: compiler aborts if the sum of space needed by all arguments ! 147: exceeds 14 words. This is because the arguments are passed in ! 148: registers (R0..R13) not on the stack, and there is a problem with ! 149: passing further arguments (i.e. beyond those in R0..R13) via the ! 150: stack. ! 151: ! 152: If efficiency is less important than using long argument lists, you ! 153: can change the definition of the `FUNCTION_ARG' macro in ! 154: `config/1750/1750a.h' to always return zero. If you do that, GNU ! 155: CC will pass all parameters on the stack. ! 156: ! 157: `alpha-*-osf1' ! 158: Systems using processors that implement the DEC Alpha architecture ! 159: and are running the OSF/1 operating system, for example the DEC ! 160: Alpha AXP systems. (VMS on the Alpha is not currently supported ! 161: by GNU CC.) ! 162: ! 163: GNU CC writes a `.verstamp' directive to the assembler output file ! 164: unless it is built as a cross-compiler. It gets the version to ! 165: use from the system header file `/usr/include/stamp.h'. If you ! 166: install a new version of OSF/1, you should rebuild GCC to pick up ! 167: the new version stamp. ! 168: ! 169: Note that since the Alpha is a 64-bit architecture, ! 170: cross-compilers from 32-bit machines will not generate code as ! 171: efficient as that generated when the compiler is running on a ! 172: 64-bit machine because many optimizations that depend on being ! 173: able to represent a word on the target in an integral value on the ! 174: host cannot be performed. Building cross-compilers on the Alpha ! 175: for 32-bit machines has only been tested in a few cases and may ! 176: not work properly. ! 177: ! 178: `make compare' may fail on old versions of OSF/1 unless you add ! 179: `-save-temps' to `CFLAGS'. On these systems, the name of the ! 180: assembler input file is stored in the object file, and that makes ! 181: comparison fail if it differs between the `stage1' and `stage2' ! 182: compilations. The option `-save-temps' forces a fixed name to be ! 183: used for the assembler input file, instead of a randomly chosen ! 184: name in `/tmp'. Do not add `-save-temps' unless the comparisons ! 185: fail without that option. If you add `-save-temps', you will have ! 186: to manually delete the `.i' and `.s' files after each series of ! 187: compilations. ! 188: ! 189: GNU CC now supports both the native (ECOFF) debugging format used ! 190: by DBX and GDB and an encapsulated STABS format for use only with ! 191: GDB. See the discussion of the `--with-stabs' option of ! 192: `configure' above for more information on these formats and how to ! 193: select them. ! 194: ! 195: There is a bug in DEC's assembler that produces incorrect line ! 196: numbers for ECOFF format when the `.align' directive is used. To ! 197: work around this problem, GNU CC will not emit such alignment ! 198: directives while writing ECOFF format debugging information even ! 199: if optimization is being performed. Unfortunately, this has the ! 200: very undesirable side-effect that code addresses when `-O' is ! 201: specified are different depending on whether or not `-g' is also ! 202: specified. ! 203: ! 204: To avoid this behavior, specify `-gstabs+' and use GDB instead of ! 205: DBX. DEC is now aware of this problem with the assembler and ! 206: hopes to provide a fix shortly. ! 207: ! 208: `arm' ! 209: Advanced RISC Machines ARM-family processors. These are often ! 210: used in embedded applications. There are no standard Unix ! 211: configurations. This configuration corresponds to the basic ! 212: instruction sequences and will produce a.out format object modules. ! 213: ! 214: You may need to make a variant of the file `arm.h' for your ! 215: particular configuration. ! 216: ! 217: `arm-*-riscix' ! 218: The ARM2 or ARM3 processor running RISC iX, Acorn's port of BSD ! 219: Unix. If you are running a version of RISC iX prior to 1.2 then ! 220: you must specify the version number during configuration. Note ! 221: that the assembler shipped with RISC iX does not support stabs ! 222: debugging information; a new version of the assembler, with stabs ! 223: support included, is now available from Acorn. ! 224: ! 225: `a29k' ! 226: AMD Am29k-family processors. These are normally used in embedded ! 227: applications. There are no standard Unix configurations. This ! 228: configuration corresponds to AMD's standard calling sequence and ! 229: binary interface and is compatible with other 29k tools. ! 230: ! 231: You may need to make a variant of the file `a29k.h' for your ! 232: particular configuration. ! 233: ! 234: `a29k-*-bsd' ! 235: AMD Am29050 used in a system running a variant of BSD Unix. ! 236: ! 237: `decstation-*' ! 238: DECstations can support three different personalities: Ultrix, DEC ! 239: OSF/1, and OSF/rose. To configure GCC for these platforms use the ! 240: following configurations: ! 241: ! 242: `decstation-ultrix' ! 243: Ultrix configuration. ! 244: ! 245: `decstation-osf1' ! 246: Dec's version of OSF/1. ! 247: ! 248: `decstation-osfrose' ! 249: Open Software Foundation reference port of OSF/1 which uses ! 250: the OSF/rose object file format instead of ECOFF. Normally, ! 251: you would not select this configuration. ! 252: ! 253: The MIPS C compiler needs to be told to increase its table size ! 254: for switch statements with the `-Wf,-XNg1500' option in order to ! 255: compile `cp/parse.c'. If you use the `-O2' optimization option, ! 256: you also need to use `-Olimit 3000'. Both of these options are ! 257: automatically generated in the `Makefile' that the shell script ! 258: `configure' builds. If you override the `CC' make variable and ! 259: use the MIPS compilers, you may need to add `-Wf,-XNg1500 -Olimit ! 260: 3000'. ! 261: ! 262: `elxsi-elxsi-bsd' ! 263: The Elxsi's C compiler has known limitations that prevent it from ! 264: compiling GNU C. Please contact `[email protected]' for more details. ! 265: ! 266: `dsp16xx' ! 267: A port to the AT&T DSP1610 family of processors. ! 268: ! 269: `h8300-*-*' ! 270: The calling convention and structure layout has changed in release ! 271: 2.6. All code must be recompiled. The calling convention now ! 272: passes the first three arguments in function calls in registers. ! 273: Structures are no longer a multiple of 2 bytes. ! 274: ! 275: `hppa*-*-*' ! 276: There are two variants of this CPU, called 1.0 and 1.1, which have ! 277: different machine descriptions. You must use the right one for ! 278: your machine. All 7NN machines and 8N7 machines use 1.1, while ! 279: all other 8NN machines use 1.0. ! 280: ! 281: The easiest way to handle this problem is to use `configure hpNNN' ! 282: or `configure hpNNN-hpux', where NNN is the model number of the ! 283: machine. Then `configure' will figure out if the machine is a 1.0 ! 284: or 1.1. Use `uname -a' to find out the model number of your ! 285: machine. ! 286: ! 287: `-g' does not work on HP-UX, since that system uses a peculiar ! 288: debugging format which GNU CC does not know about. However, `-g' ! 289: will work if you also use GAS and GDB in conjunction with GCC. We ! 290: highly recommend using GAS for all HP-PA configurations. ! 291: ! 292: You should be using GAS-2.3 (or later) along with GDB-4.12 (or ! 293: later). These can be retrieved from all the traditional GNU ftp ! 294: archive sites. ! 295: ! 296: Build GAS and install the resulting binary as: ! 297: ! 298: /usr/local/lib/gcc-lib/CONFIGURATION/GCCVERSION/as ! 299: ! 300: where CONFIGURATION is the configuration name (perhaps ! 301: `hpNNN-hpux') and GCCVERSION is the GNU CC version number. Do ! 302: this *before* starting the build process, otherwise you will get ! 303: errors from the HPUX assembler while building `libgcc2.a'. The ! 304: command ! 305: ! 306: make install-dir ! 307: ! 308: will create the necessary directory hierarchy so you can install ! 309: GAS before building GCC. ! 310: ! 311: To enable debugging, configure GNU CC with the `--with-gnu-as' ! 312: option before building. ! 313: ! 314: It has been reported that GNU CC produces invalid assembly code for ! 315: 1.1 machines running HP-UX 8.02 when using the HP assembler. ! 316: Typically the errors look like this: ! 317: as: bug.s @line#15 [err#1060] ! 318: Argument 0 or 2 in FARG upper ! 319: - lookahead = ARGW1=FR,RTNVAL=GR ! 320: as: foo.s @line#28 [err#1060] ! 321: Argument 0 or 2 in FARG upper ! 322: - lookahead = ARGW1=FR ! 323: ! 324: You can check the version of HP-UX you are running by executing ! 325: the command `uname -r'. If you are indeed running HP-UX 8.02 on ! 326: a PA and using the HP assembler then configure GCC with ! 327: "hpNNN-hpux8.02". ! 328: ! 329: `i370-*-*' ! 330: This port is very preliminary and has many known bugs. We hope to ! 331: have a higher-quality port for this machine soon. ! 332: ! 333: `i386-*-gnu/linux' ! 334: Bash-1.12 has a bug that causes configure to fail. The symptom is ! 335: that the c++ subdirectory, `cp', is not configured. Bash-1.14 and ! 336: later work fine. ! 337: ! 338: `i386-*-sco' ! 339: Compilation with RCC is recommended. Also, it may be a good idea ! 340: to link with GNU malloc instead of the malloc that comes with the ! 341: system. ! 342: ! 343: `i386-*-sco3.2.4' ! 344: Use this configuration for SCO release 3.2 version 4. ! 345: ! 346: `i386-*-isc' ! 347: It may be a good idea to link with GNU malloc instead of the ! 348: malloc that comes with the system. ! 349: ! 350: In ISC version 4.1, `sed' core dumps when building `deduced.h'. ! 351: Use the version of `sed' from version 4.0. ! 352: ! 353: `i386-*-esix' ! 354: It may be good idea to link with GNU malloc instead of the malloc ! 355: that comes with the system. ! 356: ! 357: `i386-ibm-aix' ! 358: You need to use GAS version 2.1 or later, and and LD from GNU ! 359: binutils version 2.2 or later. ! 360: ! 361: `i386-sequent-bsd' ! 362: Go to the Berkeley universe before compiling. In addition, you ! 363: probably need to create a file named `string.h' containing just ! 364: one line: `#include <strings.h>'. ! 365: ! 366: `i386-sequent-ptx1*' ! 367: Sequent DYNIX/ptx 1.x. ! 368: ! 369: `i386-sequent-ptx2*' ! 370: Sequent DYNIX/ptx 2.x. ! 371: ! 372: `i386-sun-sunos4' ! 373: You may find that you need another version of GNU CC to begin ! 374: bootstrapping with, since the current version when built with the ! 375: system's own compiler seems to get an infinite loop compiling part ! 376: of `libgcc2.c'. GNU CC version 2 compiled with GNU CC (any ! 377: version) seems not to have this problem. ! 378: ! 379: See *Note Sun Install::, for information on installing GNU CC on ! 380: Sun systems. ! 381: ! 382: `i860-intel-osf1' ! 383: This is the Paragon. If you have version 1.0 of the operating ! 384: system, see *Note Installation Problems::, for special things you ! 385: need to do to compensate for peculiarities in the system. ! 386: ! 387: `m68000-hp-bsd' ! 388: HP 9000 series 200 running BSD. Note that the C compiler that ! 389: comes with this system cannot compile GNU CC; contact ! 390: `[email protected]' to get binaries of GNU CC for bootstrapping. ! 391: ! 392: `m68k-altos' ! 393: Altos 3068. You must use the GNU assembler, linker and debugger. ! 394: Also, you must fix a kernel bug. Details in the file ! 395: `README.ALTOS'. ! 396: ! 397: `m68k-att-sysv' ! 398: AT&T 3b1, a.k.a. 7300 PC. Special procedures are needed to ! 399: compile GNU CC with this machine's standard C compiler, due to ! 400: bugs in that compiler. You can bootstrap it more easily with ! 401: previous versions of GNU CC if you have them. ! 402: ! 403: Installing GNU CC on the 3b1 is difficult if you do not already ! 404: have GNU CC running, due to bugs in the installed C compiler. ! 405: However, the following procedure might work. We are unable to ! 406: test it. ! 407: ! 408: 1. Comment out the `#include "config.h"' line on line 37 of ! 409: `cccp.c' and do `make cpp'. This makes a preliminary version ! 410: of GNU cpp. ! 411: ! 412: 2. Save the old `/lib/cpp' and copy the preliminary GNU cpp to ! 413: that file name. ! 414: ! 415: 3. Undo your change in `cccp.c', or reinstall the original ! 416: version, and do `make cpp' again. ! 417: ! 418: 4. Copy this final version of GNU cpp into `/lib/cpp'. ! 419: ! 420: 5. Replace every occurrence of `obstack_free' in the file ! 421: `tree.c' with `_obstack_free'. ! 422: ! 423: 6. Run `make' to get the first-stage GNU CC. ! 424: ! 425: 7. Reinstall the original version of `/lib/cpp'. ! 426: ! 427: 8. Now you can compile GNU CC with itself and install it in the ! 428: normal fashion. ! 429: ! 430: `m68k-bull-sysv' ! 431: Bull DPX/2 series 200 and 300 with BOS-2.00.45 up to BOS-2.01. GNU ! 432: CC works either with native assembler or GNU assembler. You can use ! 433: GNU assembler with native coff generation by providing ! 434: `--with-gnu-as' to the configure script or use GNU assembler with ! 435: dbx-in-coff encapsulation by providing `--with-gnu-as --stabs'. ! 436: For any problem with native assembler or for availability of the ! 437: DPX/2 port of GAS, contact `[email protected]'. ! 438: ! 439: `m68k-crds-unox' ! 440: Use `configure unos' for building on Unos. ! 441: ! 442: The Unos assembler is named `casm' instead of `as'. For some ! 443: strange reason linking `/bin/as' to `/bin/casm' changes the ! 444: behavior, and does not work. So, when installing GNU CC, you ! 445: should install the following script as `as' in the subdirectory ! 446: where the passes of GCC are installed: ! 447: ! 448: #!/bin/sh ! 449: casm $* ! 450: ! 451: The default Unos library is named `libunos.a' instead of `libc.a'. ! 452: To allow GNU CC to function, either change all references to ! 453: `-lc' in `gcc.c' to `-lunos' or link `/lib/libc.a' to ! 454: `/lib/libunos.a'. ! 455: ! 456: When compiling GNU CC with the standard compiler, to overcome bugs ! 457: in the support of `alloca', do not use `-O' when making stage 2. ! 458: Then use the stage 2 compiler with `-O' to make the stage 3 ! 459: compiler. This compiler will have the same characteristics as the ! 460: usual stage 2 compiler on other systems. Use it to make a stage 4 ! 461: compiler and compare that with stage 3 to verify proper ! 462: compilation. ! 463: ! 464: (Perhaps simply defining `ALLOCA' in `x-crds' as described in the ! 465: comments there will make the above paragraph superfluous. Please ! 466: inform us of whether this works.) ! 467: ! 468: Unos uses memory segmentation instead of demand paging, so you ! 469: will need a lot of memory. 5 Mb is barely enough if no other ! 470: tasks are running. If linking `cc1' fails, try putting the object ! 471: files into a library and linking from that library. ! 472: ! 473: `m68k-hp-hpux' ! 474: HP 9000 series 300 or 400 running HP-UX. HP-UX version 8.0 has a ! 475: bug in the assembler that prevents compilation of GNU CC. To fix ! 476: it, get patch PHCO_4484 from HP. ! 477: ! 478: In addition, if you wish to use gas `--with-gnu-as' you must use ! 479: gas version 2.1 or later, and you must use the GNU linker version ! 480: 2.1 or later. Earlier versions of gas relied upon a program which ! 481: converted the gas output into the native HP/UX format, but that ! 482: program has not been kept up to date. gdb does not understand ! 483: that native HP/UX format, so you must use gas if you wish to use ! 484: gdb. ! 485: ! 486: `m68k-sun' ! 487: Sun 3. We do not provide a configuration file to use the Sun FPA ! 488: by default, because programs that establish signal handlers for ! 489: floating point traps inherently cannot work with the FPA. ! 490: ! 491: See *Note Sun Install::, for information on installing GNU CC on ! 492: Sun systems. ! 493: ! 494: `m88k-*-svr3' ! 495: Motorola m88k running the AT&T/Unisoft/Motorola V.3 reference port. ! 496: These systems tend to use the Green Hills C, revision 1.8.5, as the ! 497: standard C compiler. There are apparently bugs in this compiler ! 498: that result in object files differences between stage 2 and stage ! 499: 3. If this happens, make the stage 4 compiler and compare it to ! 500: the stage 3 compiler. If the stage 3 and stage 4 object files are ! 501: identical, this suggests you encountered a problem with the ! 502: standard C compiler; the stage 3 and 4 compilers may be usable. ! 503: ! 504: It is best, however, to use an older version of GNU CC for ! 505: bootstrapping if you have one. ! 506: ! 507: `m88k-*-dgux' ! 508: Motorola m88k running DG/UX. To build 88open BCS native or cross ! 509: compilers on DG/UX, specify the configuration name as ! 510: `m88k-*-dguxbcs' and build in the 88open BCS software development ! 511: environment. To build ELF native or cross compilers on DG/UX, ! 512: specify `m88k-*-dgux' and build in the DG/UX ELF development ! 513: environment. You set the software development environment by ! 514: issuing `sde-target' command and specifying either `m88kbcs' or ! 515: `m88kdguxelf' as the operand. ! 516: ! 517: If you do not specify a configuration name, `configure' guesses the ! 518: configuration based on the current software development ! 519: environment. ! 520: ! 521: `m88k-tektronix-sysv3' ! 522: Tektronix XD88 running UTekV 3.2e. Do not turn on optimization ! 523: while building stage1 if you bootstrap with the buggy Green Hills ! 524: compiler. Also, The bundled LAI System V NFS is buggy so if you ! 525: build in an NFS mounted directory, start from a fresh reboot, or ! 526: avoid NFS all together. Otherwise you may have trouble getting ! 527: clean comparisons between stages. ! 528: ! 529: `mips-mips-bsd' ! 530: MIPS machines running the MIPS operating system in BSD mode. It's ! 531: possible that some old versions of the system lack the functions ! 532: `memcpy', `memcmp', and `memset'. If your system lacks these, you ! 533: must remove or undo the definition of `TARGET_MEM_FUNCTIONS' in ! 534: `mips-bsd.h'. ! 535: ! 536: The MIPS C compiler needs to be told to increase its table size ! 537: for switch statements with the `-Wf,-XNg1500' option in order to ! 538: compile `cp/parse.c'. If you use the `-O2' optimization option, ! 539: you also need to use `-Olimit 3000'. Both of these options are ! 540: automatically generated in the `Makefile' that the shell script ! 541: `configure' builds. If you override the `CC' make variable and ! 542: use the MIPS compilers, you may need to add `-Wf,-XNg1500 -Olimit ! 543: 3000'. ! 544: ! 545: `mips-mips-riscos*' ! 546: The MIPS C compiler needs to be told to increase its table size ! 547: for switch statements with the `-Wf,-XNg1500' option in order to ! 548: compile `cp/parse.c'. If you use the `-O2' optimization option, ! 549: you also need to use `-Olimit 3000'. Both of these options are ! 550: automatically generated in the `Makefile' that the shell script ! 551: `configure' builds. If you override the `CC' make variable and ! 552: use the MIPS compilers, you may need to add `-Wf,-XNg1500 -Olimit ! 553: 3000'. ! 554: ! 555: MIPS computers running RISC-OS can support four different ! 556: personalities: default, BSD 4.3, System V.3, and System V.4 (older ! 557: versions of RISC-OS don't support V.4). To configure GCC for ! 558: these platforms use the following configurations: ! 559: ! 560: `mips-mips-riscos`rev'' ! 561: Default configuration for RISC-OS, revision `rev'. ! 562: ! 563: `mips-mips-riscos`rev'bsd' ! 564: BSD 4.3 configuration for RISC-OS, revision `rev'. ! 565: ! 566: `mips-mips-riscos`rev'sysv4' ! 567: System V.4 configuration for RISC-OS, revision `rev'. ! 568: ! 569: `mips-mips-riscos`rev'sysv' ! 570: System V.3 configuration for RISC-OS, revision `rev'. ! 571: ! 572: The revision `rev' mentioned above is the revision of RISC-OS to ! 573: use. You must reconfigure GCC when going from a RISC-OS revision ! 574: 4 to RISC-OS revision 5. This has the effect of avoiding a linker ! 575: bug (see *Note Installation Problems::, for more details). ! 576: ! 577: `mips-sgi-*' ! 578: In order to compile GCC on an SGI running IRIX 4, the "c.hdr.lib" ! 579: option must be installed from the CD-ROM supplied from Silicon ! 580: Graphics. This is found on the 2nd CD in release 4.0.1. ! 581: ! 582: `make compare' may fail on version 5 of IRIX unless you add ! 583: `-save-temps' to `CFLAGS'. On these systems, the name of the ! 584: assembler input file is stored in the object file, and that makes ! 585: comparison fail if it differs between the `stage1' and `stage2' ! 586: compilations. The option `-save-temps' forces a fixed name to be ! 587: used for the assembler input file, instead of a randomly chosen ! 588: name in `/tmp'. Do not add `-save-temps' unless the comparisons ! 589: fail without that option. If you do you `-save-temps', you will ! 590: have to manually delete the `.i' and `.s' files after each series ! 591: of compilations. ! 592: ! 593: The MIPS C compiler needs to be told to increase its table size ! 594: for switch statements with the `-Wf,-XNg1500' option in order to ! 595: compile `cp/parse.c'. If you use the `-O2' optimization option, ! 596: you also need to use `-Olimit 3000'. Both of these options are ! 597: automatically generated in the `Makefile' that the shell script ! 598: `configure' builds. If you override the `CC' make variable and ! 599: use the MIPS compilers, you may need to add `-Wf,-XNg1500 -Olimit ! 600: 3000'. ! 601: ! 602: On Irix version 4.0.5F, and perhaps on some other versions as well, ! 603: there is an assembler bug that reorders instructions incorrectly. ! 604: To work around it, specify the target configuration ! 605: `mips-sgi-irix4loser'. This configuration inhibits assembler ! 606: optimization. ! 607: ! 608: In a compiler configured with target `mips-sgi-irix4', you can turn ! 609: off assembler optimization by using the `-noasmopt' option. This ! 610: compiler option passes the option `-O0' to the assembler, to ! 611: inhibit reordering. ! 612: ! 613: The `-noasmopt' option can be useful for testing whether a problem ! 614: is due to erroneous assembler reordering. Even if a problem does ! 615: not go away with `-noasmopt', it may still be due to assembler ! 616: reordering--perhaps GNU CC itself was miscompiled as a result. ! 617: ! 618: To enable debugging under Irix 5, you must use GNU as 2.5 or later, ! 619: and use the -with-gnu-as configure option when configuring gcc. ! 620: GNU as is distributed as part of the binutils package. ! 621: ! 622: `mips-sony-sysv' ! 623: Sony MIPS NEWS. This works in NEWSOS 5.0.1, but not in 5.0.2 ! 624: (which uses ELF instead of COFF). Support for 5.0.2 will probably ! 625: be provided soon by volunteers. In particular, the linker does ! 626: not like the code generated by GCC when shared libraries are ! 627: linked in. ! 628: ! 629: `ns32k-encore' ! 630: Encore ns32000 system. Encore systems are supported only under ! 631: BSD. ! 632: ! 633: `ns32k-*-genix' ! 634: National Semiconductor ns32000 system. Genix has bugs in `alloca' ! 635: and `malloc'; you must get the compiled versions of these from GNU ! 636: Emacs. ! 637: ! 638: `ns32k-sequent' ! 639: Go to the Berkeley universe before compiling. In addition, you ! 640: probably need to create a file named `string.h' containing just ! 641: one line: `#include <strings.h>'. ! 642: ! 643: `ns32k-utek' ! 644: UTEK ns32000 system ("merlin"). The C compiler that comes with ! 645: this system cannot compile GNU CC; contact `tektronix!reed!mason' ! 646: to get binaries of GNU CC for bootstrapping. ! 647: ! 648: `romp-*-aos' ! 649: `romp-*-mach' ! 650: The only operating systems supported for the IBM RT PC are AOS and ! 651: MACH. GNU CC does not support AIX running on the RT. We ! 652: recommend you compile GNU CC with an earlier version of itself; if ! 653: you compile GNU CC with `hc', the Metaware compiler, it will work, ! 654: but you will get mismatches between the stage 2 and stage 3 ! 655: compilers in various files. These errors are minor differences in ! 656: some floating-point constants and can be safely ignored; the stage ! 657: 3 compiler is correct. ! 658: ! 659: `rs6000-*-aix' ! 660: `powerpc-*-aix' ! 661: Various early versions of each release of the IBM XLC compiler ! 662: will not bootstrap GNU CC. Symptoms include differences between ! 663: the stage2 and stage3 object files, and errors when compiling ! 664: `libgcc.a' or `enquire'. Known problematic releases include: ! 665: xlc-1.2.1.8, xlc-1.3.0.0 (distributed with AIX 3.2.5), and ! 666: xlc-1.3.0.19. Both xlc-1.2.1.28 and xlc-1.3.0.24 (PTF 432238) are ! 667: known to produce working versions of GNU CC, but most other recent ! 668: releases correctly bootstrap GNU CC. Also, releases of AIX prior ! 669: to AIX 3.2.4 include a version of the IBM assembler which does not ! 670: accept debugging directives: assembler updates are available as ! 671: PTFs. See the file `README.RS6000' for more details on both of ! 672: these problems. ! 673: ! 674: Only AIX is supported on the PowerPC. GNU CC does not yet support ! 675: the 64-bit PowerPC instructions. ! 676: ! 677: Objective C does not work on this architecture. ! 678: ! 679: AIX on the RS/6000 provides support (NLS) for environments outside ! 680: of the United States. Compilers and assemblers use NLS to support ! 681: locale-specific representations of various objects including ! 682: floating-point numbers ("." vs "," for separating decimal ! 683: fractions). There have been problems reported where the library ! 684: linked with GNU CC does not produce the same floating-point ! 685: formats that the assembler accepts. If you have this problem, set ! 686: the LANG environment variable to "C" or "En_US". ! 687: ! 688: `vax-dec-ultrix' ! 689: Don't try compiling with Vax C (`vcc'). It produces incorrect code ! 690: in some cases (for example, when `alloca' is used). ! 691: ! 692: Meanwhile, compiling `cp/parse.c' with pcc does not work because of ! 693: an internal table size limitation in that compiler. To avoid this ! 694: problem, compile just the GNU C compiler first, and use it to ! 695: recompile building all the languages that you want to run. ! 696: ! 697: `sparc-sun-*' ! 698: See *Note Sun Install::, for information on installing GNU CC on ! 699: Sun systems. ! 700: ! 701: `vax-dec-vms' ! 702: See *Note VMS Install::, for details on how to install GNU CC on ! 703: VMS. ! 704: ! 705: `we32k-*-*' ! 706: These computers are also known as the 3b2, 3b5, 3b20 and other ! 707: similar names. (However, the 3b1 is actually a 68000; see *Note ! 708: Configurations::.) ! 709: ! 710: Don't use `-g' when compiling with the system's compiler. The ! 711: system's linker seems to be unable to handle such a large program ! 712: with debugging information. ! 713: ! 714: The system's compiler runs out of capacity when compiling `stmt.c' ! 715: in GNU CC. You can work around this by building `cpp' in GNU CC ! 716: first, then use that instead of the system's preprocessor with the ! 717: system's C compiler to compile `stmt.c'. Here is how: ! 718: ! 719: mv /lib/cpp /lib/cpp.att ! 720: cp cpp /lib/cpp.gnu ! 721: echo '/lib/cpp.gnu -traditional ${1+"$@"}' > /lib/cpp ! 722: chmod +x /lib/cpp ! 723: ! 724: The system's compiler produces bad code for some of the GNU CC ! 725: optimization files. So you must build the stage 2 compiler without ! 726: optimization. Then build a stage 3 compiler with optimization. ! 727: That executable should work. Here are the necessary commands: ! 728: ! 729: make LANGUAGES=c CC=stage1/xgcc CFLAGS="-Bstage1/ -g" ! 730: make stage2 ! 731: make CC=stage2/xgcc CFLAGS="-Bstage2/ -g -O" ! 732: ! 733: You may need to raise the ULIMIT setting to build a C++ compiler, ! 734: as the file `cc1plus' is larger than one megabyte. ! 735: ! 736: ! 737: File: gcc.info, Node: Other Dir, Next: Cross-Compiler, Prev: Configurations, Up: Installation ! 738: ! 739: Compilation in a Separate Directory ! 740: =================================== ! 741: ! 742: If you wish to build the object files and executables in a directory ! 743: other than the one containing the source files, here is what you must ! 744: do differently: ! 745: ! 746: 1. Make sure you have a version of Make that supports the `VPATH' ! 747: feature. (GNU Make supports it, as do Make versions on most BSD ! 748: systems.) ! 749: ! 750: 2. If you have ever run `configure' in the source directory, you must ! 751: undo the configuration. Do this by running: ! 752: ! 753: make distclean ! 754: ! 755: 3. Go to the directory in which you want to build the compiler before ! 756: running `configure': ! 757: ! 758: mkdir gcc-sun3 ! 759: cd gcc-sun3 ! 760: ! 761: On systems that do not support symbolic links, this directory must ! 762: be on the same file system as the source code directory. ! 763: ! 764: 4. Specify where to find `configure' when you run it: ! 765: ! 766: ../gcc/configure ... ! 767: ! 768: This also tells `configure' where to find the compiler sources; ! 769: `configure' takes the directory from the file name that was used to ! 770: invoke it. But if you want to be sure, you can specify the source ! 771: directory with the `--srcdir' option, like this: ! 772: ! 773: ../gcc/configure --srcdir=../gcc OTHER OPTIONS ! 774: ! 775: The directory you specify with `--srcdir' need not be the same as ! 776: the one that `configure' is found in. ! 777: ! 778: Now, you can run `make' in that directory. You need not repeat the ! 779: configuration steps shown above, when ordinary source files change. You ! 780: must, however, run `configure' again when the configuration files ! 781: change, if your system does not support symbolic links. ! 782: ! 783: ! 784: File: gcc.info, Node: Cross-Compiler, Next: Sun Install, Prev: Other Dir, Up: Installation ! 785: ! 786: Building and Installing a Cross-Compiler ! 787: ======================================== ! 788: ! 789: GNU CC can function as a cross-compiler for many machines, but not ! 790: all. ! 791: ! 792: * Cross-compilers for the Mips as target using the Mips assembler ! 793: currently do not work, because the auxiliary programs ! 794: `mips-tdump.c' and `mips-tfile.c' can't be compiled on anything ! 795: but a Mips. It does work to cross compile for a Mips if you use ! 796: the GNU assembler and linker. ! 797: ! 798: * Cross-compilers between machines with different floating point ! 799: formats have not all been made to work. GNU CC now has a floating ! 800: point emulator with which these can work, but each target machine ! 801: description needs to be updated to take advantage of it. ! 802: ! 803: * Cross-compilation between machines of different word sizes is ! 804: somewhat problematic and sometimes does not work. ! 805: ! 806: Since GNU CC generates assembler code, you probably need a ! 807: cross-assembler that GNU CC can run, in order to produce object files. ! 808: If you want to link on other than the target machine, you need a ! 809: cross-linker as well. You also need header files and libraries suitable ! 810: for the target machine that you can install on the host machine. ! 811: ! 812: * Menu: ! 813: ! 814: * Steps of Cross:: Using a cross-compiler involves several steps ! 815: that may be carried out on different machines. ! 816: * Configure Cross:: Configuring a cross-compiler. ! 817: * Tools and Libraries:: Where to put the linker and assembler, and the C library. ! 818: * Cross Headers:: Finding and installing header files ! 819: for a cross-compiler. ! 820: * Cross Runtime:: Supplying arithmetic runtime routines (`libgcc1.a'). ! 821: * Build Cross:: Actually compiling the cross-compiler. ! 822: ! 823: ! 824: File: gcc.info, Node: Steps of Cross, Next: Configure Cross, Up: Cross-Compiler ! 825: ! 826: Steps of Cross-Compilation ! 827: -------------------------- ! 828: ! 829: To compile and run a program using a cross-compiler involves several ! 830: steps: ! 831: ! 832: * Run the cross-compiler on the host machine to produce assembler ! 833: files for the target machine. This requires header files for the ! 834: target machine. ! 835: ! 836: * Assemble the files produced by the cross-compiler. You can do this ! 837: either with an assembler on the target machine, or with a ! 838: cross-assembler on the host machine. ! 839: ! 840: * Link those files to make an executable. You can do this either ! 841: with a linker on the target machine, or with a cross-linker on the ! 842: host machine. Whichever machine you use, you need libraries and ! 843: certain startup files (typically `crt....o') for the target ! 844: machine. ! 845: ! 846: It is most convenient to do all of these steps on the same host ! 847: machine, since then you can do it all with a single invocation of GNU ! 848: CC. This requires a suitable cross-assembler and cross-linker. For ! 849: some targets, the GNU assembler and linker are available. ! 850: ! 851: ! 852: File: gcc.info, Node: Configure Cross, Next: Tools and Libraries, Prev: Steps of Cross, Up: Cross-Compiler ! 853: ! 854: Configuring a Cross-Compiler ! 855: ---------------------------- ! 856: ! 857: To build GNU CC as a cross-compiler, you start out by running ! 858: `configure'. Use the `--target=TARGET' to specify the target type. If ! 859: `configure' was unable to correctly identify the system you are running ! 860: on, also specify the `--build=BUILD' option. For example, here is how ! 861: to configure for a cross-compiler that produces code for an HP 68030 ! 862: system running BSD on a system that `configure' can correctly identify: ! 863: ! 864: ./configure --target=m68k-hp-bsd4.3 ! 865: ! 866: ! 867: File: gcc.info, Node: Tools and Libraries, Next: Cross Headers, Prev: Configure Cross, Up: Cross-Compiler ! 868: ! 869: Tools and Libraries for a Cross-Compiler ! 870: ---------------------------------------- ! 871: ! 872: If you have a cross-assembler and cross-linker available, you should ! 873: install them now. Put them in the directory `/usr/local/TARGET/bin'. ! 874: Here is a table of the tools you should put in this directory: ! 875: ! 876: `as' ! 877: This should be the cross-assembler. ! 878: ! 879: `ld' ! 880: This should be the cross-linker. ! 881: ! 882: `ar' ! 883: This should be the cross-archiver: a program which can manipulate ! 884: archive files (linker libraries) in the target machine's format. ! 885: ! 886: `ranlib' ! 887: This should be a program to construct a symbol table in an archive ! 888: file. ! 889: ! 890: The installation of GNU CC will find these programs in that ! 891: directory, and copy or link them to the proper place to for the ! 892: cross-compiler to find them when run later. ! 893: ! 894: The easiest way to provide these files is to build the Binutils ! 895: package and GAS. Configure them with the same `--host' and `--target' ! 896: options that you use for configuring GNU CC, then build and install ! 897: them. They install their executables automatically into the proper ! 898: directory. Alas, they do not support all the targets that GNU CC ! 899: supports. ! 900: ! 901: If you want to install libraries to use with the cross-compiler, ! 902: such as a standard C library, put them in the directory ! 903: `/usr/local/TARGET/lib'; installation of GNU CC copies all all the ! 904: files in that subdirectory into the proper place for GNU CC to find ! 905: them and link with them. Here's an example of copying some libraries ! 906: from a target machine: ! 907: ! 908: ftp TARGET-MACHINE ! 909: lcd /usr/local/TARGET/lib ! 910: cd /lib ! 911: get libc.a ! 912: cd /usr/lib ! 913: get libg.a ! 914: get libm.a ! 915: quit ! 916: ! 917: The precise set of libraries you'll need, and their locations on the ! 918: target machine, vary depending on its operating system. ! 919: ! 920: Many targets require "start files" such as `crt0.o' and `crtn.o' ! 921: which are linked into each executable; these too should be placed in ! 922: `/usr/local/TARGET/lib'. There may be several alternatives for ! 923: `crt0.o', for use with profiling or other compilation options. Check ! 924: your target's definition of `STARTFILE_SPEC' to find out what start ! 925: files it uses. Here's an example of copying these files from a target ! 926: machine: ! 927: ! 928: ftp TARGET-MACHINE ! 929: lcd /usr/local/TARGET/lib ! 930: prompt ! 931: cd /lib ! 932: mget *crt*.o ! 933: cd /usr/lib ! 934: mget *crt*.o ! 935: quit ! 936: ! 937: ! 938: File: gcc.info, Node: Cross Runtime, Next: Build Cross, Prev: Cross Headers, Up: Cross-Compiler ! 939: ! 940: `libgcc.a' and Cross-Compilers ! 941: ------------------------------ ! 942: ! 943: Code compiled by GNU CC uses certain runtime support functions ! 944: implicitly. Some of these functions can be compiled successfully with ! 945: GNU CC itself, but a few cannot be. These problem functions are in the ! 946: source file `libgcc1.c'; the library made from them is called ! 947: `libgcc1.a'. ! 948: ! 949: When you build a native compiler, these functions are compiled with ! 950: some other compiler-the one that you use for bootstrapping GNU CC. ! 951: Presumably it knows how to open code these operations, or else knows how ! 952: to call the run-time emulation facilities that the machine comes with. ! 953: But this approach doesn't work for building a cross-compiler. The ! 954: compiler that you use for building knows about the host system, not the ! 955: target system. ! 956: ! 957: So, when you build a cross-compiler you have to supply a suitable ! 958: library `libgcc1.a' that does the job it is expected to do. ! 959: ! 960: To compile `libgcc1.c' with the cross-compiler itself does not work. ! 961: The functions in this file are supposed to implement arithmetic ! 962: operations that GNU CC does not know how to open code, for your target ! 963: machine. If these functions are compiled with GNU CC itself, they will ! 964: compile into infinite recursion. ! 965: ! 966: On any given target, most of these functions are not needed. If GNU ! 967: CC can open code an arithmetic operation, it will not call these ! 968: functions to perform the operation. It is possible that on your target ! 969: machine, none of these functions is needed. If so, you can supply an ! 970: empty library as `libgcc1.a'. ! 971: ! 972: Many targets need library support only for multiplication and ! 973: division. If you are linking with a library that contains functions for ! 974: multiplication and division, you can tell GNU CC to call them directly ! 975: by defining the macros `MULSI3_LIBCALL', and the like. These macros ! 976: need to be defined in the target description macro file. For some ! 977: targets, they are defined already. This may be sufficient to avoid the ! 978: need for libgcc1.a; if so, you can supply an empty library. ! 979: ! 980: Some targets do not have floating point instructions; they need other ! 981: functions in `libgcc1.a', which do floating arithmetic. Recent ! 982: versions of GNU CC have a file which emulates floating point. With a ! 983: certain amount of work, you should be able to construct a floating ! 984: point emulator that can be used as `libgcc1.a'. Perhaps future ! 985: versions will contain code to do this automatically and conveniently. ! 986: That depends on whether someone wants to implement it. ! 987: ! 988: If your target system has another C compiler, you can configure GNU ! 989: CC as a native compiler on that machine, build just `libgcc1.a' with ! 990: `make libgcc1.a' on that machine, and use the resulting file with the ! 991: cross-compiler. To do this, execute the following on the target ! 992: machine: ! 993: ! 994: cd TARGET-BUILD-DIR ! 995: ./configure --host=sparc --target=sun3 ! 996: make libgcc1.a ! 997: ! 998: And then this on the host machine: ! 999: ! 1000: ftp TARGET-MACHINE ! 1001: binary ! 1002: cd TARGET-BUILD-DIR ! 1003: get libgcc1.a ! 1004: quit ! 1005: ! 1006: Another way to provide the functions you need in `libgcc1.a' is to ! 1007: define the appropriate `perform_...' macros for those functions. If ! 1008: these definitions do not use the C arithmetic operators that they are ! 1009: meant to implement, you should be able to compile them with the ! 1010: cross-compiler you are building. (If these definitions already exist ! 1011: for your target file, then you are all set.) ! 1012: ! 1013: To build `libgcc1.a' using the perform macros, use ! 1014: `LIBGCC1=libgcc1.a OLDCC=./xgcc' when building the compiler. ! 1015: Otherwise, you should place your replacement library under the name ! 1016: `libgcc1.a' in the directory in which you will build the ! 1017: cross-compiler, before you run `make'. ! 1018: ! 1019: ! 1020: File: gcc.info, Node: Cross Headers, Next: Cross Runtime, Prev: Tools and Libraries, Up: Cross-Compiler ! 1021: ! 1022: Cross-Compilers and Header Files ! 1023: -------------------------------- ! 1024: ! 1025: If you are cross-compiling a standalone program or a program for an ! 1026: embedded system, then you may not need any header files except the few ! 1027: that are part of GNU CC (and those of your program). However, if you ! 1028: intend to link your program with a standard C library such as `libc.a', ! 1029: then you probably need to compile with the header files that go with ! 1030: the library you use. ! 1031: ! 1032: The GNU C compiler does not come with these files, because (1) they ! 1033: are system-specific, and (2) they belong in a C library, not in a ! 1034: compiler. ! 1035: ! 1036: If the GNU C library supports your target machine, then you can get ! 1037: the header files from there (assuming you actually use the GNU library ! 1038: when you link your program). ! 1039: ! 1040: If your target machine comes with a C compiler, it probably comes ! 1041: with suitable header files also. If you make these files accessible ! 1042: from the host machine, the cross-compiler can use them also. ! 1043: ! 1044: Otherwise, you're on your own in finding header files to use when ! 1045: cross-compiling. ! 1046: ! 1047: When you have found suitable header files, put them in ! 1048: `/usr/local/TARGET/include', before building the cross compiler. Then ! 1049: installation will run fixincludes properly and install the corrected ! 1050: versions of the header files where the compiler will use them. ! 1051: ! 1052: Provide the header files before you build the cross-compiler, because ! 1053: the build stage actually runs the cross-compiler to produce parts of ! 1054: `libgcc.a'. (These are the parts that *can* be compiled with GNU CC.) ! 1055: Some of them need suitable header files. ! 1056: ! 1057: Here's an example showing how to copy the header files from a target ! 1058: machine. On the target machine, do this: ! 1059: ! 1060: (cd /usr/include; tar cf - .) > tarfile ! 1061: ! 1062: Then, on the host machine, do this: ! 1063: ! 1064: ftp TARGET-MACHINE ! 1065: lcd /usr/local/TARGET/include ! 1066: get tarfile ! 1067: quit ! 1068: tar xf tarfile 1.1 root 1069: 1070: 1.1.1.6 root 1071: File: gcc.info, Node: Build Cross, Prev: Cross Runtime, Up: Cross-Compiler 1072: 1073: Actually Building the Cross-Compiler 1074: ------------------------------------ 1075: 1076: Now you can proceed just as for compiling a single-machine compiler 1077: through the step of building stage 1. If you have not provided some 1078: sort of `libgcc1.a', then compilation will give up at the point where 1079: it needs that file, printing a suitable error message. If you do 1080: provide `libgcc1.a', then building the compiler will automatically 1081: compile and link a test program called `cross-test'; if you get errors 1082: in the linking, it means that not all of the necessary routines in 1083: `libgcc1.a' are available. 1084: 1085: If you are making a cross-compiler for an embedded system, and there 1086: is no `stdio.h' header for it, then the compilation of `enquire' will 1087: probably fail. The job of `enquire' is to run on the target machine 1088: and figure out by experiment the nature of its floating point 1089: representation. `enquire' records its findings in the header file 1090: `float.h'. If you can't produce this file by running `enquire' on the 1091: target machine, then you will need to come up with a suitable `float.h' 1092: in some other way (or else, avoid using it in your programs). 1093: 1094: Do not try to build stage 2 for a cross-compiler. It doesn't work to 1095: rebuild GNU CC as a cross-compiler using the cross-compiler, because 1096: that would produce a program that runs on the target machine, not on the 1097: host. For example, if you compile a 386-to-68030 cross-compiler with 1098: itself, the result will not be right either for the 386 (because it was 1099: compiled into 68030 code) or for the 68030 (because it was configured 1100: for a 386 as the host). If you want to compile GNU CC into 68030 code, 1101: whether you compile it on a 68030 or with a cross-compiler on a 386, you 1102: must specify a 68030 as the host when you configure it. 1103: 1104: To install the cross-compiler, use `make install', as usual. 1105: 1106: 1.1.1.7 ! root 1107: File: gcc.info, Node: Sun Install, Next: VMS Install, Prev: Cross-Compiler, Up: Installation 1.1.1.6 root 1108: 1109: Installing GNU CC on the Sun 1110: ============================ 1111: 1112: On Solaris (version 2.1), do not use the linker or other tools in 1113: `/usr/ucb' to build GNU CC. Use `/usr/ccs/bin'. 1114: 1115: Make sure the environment variable `FLOAT_OPTION' is not set when 1116: you compile `libgcc.a'. If this option were set to `f68881' when 1117: `libgcc.a' is compiled, the resulting code would demand to be linked 1118: with a special startup file and would not link properly without special 1119: pains. 1120: 1121: There is a bug in `alloca' in certain versions of the Sun library. 1122: To avoid this bug, install the binaries of GNU CC that were compiled by 1123: GNU CC. They use `alloca' as a built-in function and never the one in 1124: the library. 1125: 1126: Some versions of the Sun compiler crash when compiling GNU CC. The 1127: problem is a segmentation fault in cpp. This problem seems to be due to 1128: the bulk of data in the environment variables. You may be able to avoid 1129: it by using the following command to compile GNU CC with Sun CC: 1130: 1131: make CC="TERMCAP=x OBJS=x LIBFUNCS=x STAGESTUFF=x cc" 1132:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.