gcc/gcc.info-7 - annotate

Return to gcc.info-7 CVS log

Up to [GCC 2.x] / gcc

Annotation of gcc/gcc.info-7, revision 1.1.1.9

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

unix.superglobalmegacorp.com

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.