Go to the previous, next section.
Here is the procedure for installing GNU CC on a Unix system.
See below for VMS systems, and modified procedures needed on other systems including HP, Sun, 3b1, SCO Unix and Unos.
The following section says how to compile in a separate directory on Unix; here we assume you compile in the same directory that contains the source files.
You cannot install GNU C by itself on MSDOS; it will not compile under any MSDOS compiler except itself. You need to get the complete compilation package DJGPP, which includes binaries as well as sources, and includes all the necessary compilation tools and libraries.
PATH. The cc command in
`/usr/ucb' uses libraries which have bugs.
If you are building a compiler to produce code for the machine it runs on, specify just one machine type, with the `--target' option; the host type will default to be the same as the target. (For information on building a cross-compiler, see section Building and Installing a Cross-Compiler.) Here is an example:
configure --target=sparc-sun-sunos4.1
If you run `configure' without specifying configuration arguments, `configure' tries to guess the type of host you are on, and uses that configuration type for both host and target. So you don't need to specify a configuration, for building a native compiler, unless `configure' cannot figure out what your configuration is.
A configuration name may be canonical or it may be more or less abbreviated.
A canonical configuration name has three parts, separated by dashes. It looks like this: `cpu-company-system'. (The three parts may themselves contain dashes; `configure' can figure out which dashes serve which purpose.) For example, `m68k-sun-sunos4.1' specifies a Sun 3.
You can also replace parts of the configuration by nicknames or aliases. For example, `sun3' stands for `m68k-sun', so `sun3-sunos4.1' is another way to specify a Sun 3. You can also use simply `sun3-sunos', since the version of SunOS is assumed by default to be version 4. `sun3-bsd' also works, since `configure' knows that the only BSD variant on a Sun 3 is SunOS.
You can specify a version number after any of the system types, and some of the CPU types. In most cases, the version is irrelevant, and will be ignored. So you might as well specify the version if you know it.
Here are the possible CPU types:
a29k, alpha, arm, cn, clipper, elxsi, h8300, hppa1.0, hppa1.1, i370, i386, i486, i860, i960, m68000, m68k, m88k, mips, ns32k, pyramid, romp, rs6000, sh, sparc, sparclite, vax, we32k.
Here are the recognized company names. As you can see, customary abbreviations are used rather than the longer official names.
alliant, altos, apollo, att, bull, cbm, convergent, convex, crds, dec, dg, dolphin, elxsi, encore, harris, hitachi, hp, ibm, intergraph, isi, mips, motorola, ncr, next, ns, omron, plexus, sequent, sgi, sony, sun, tti, unicom.
The company name is meaningful only to disambiguate when the rest of the information supplied is insufficient. You can omit it, writing just `cpu-system', if it is not needed. For example, `vax-ultrix4.2' is equivalent to `vax-dec-ultrix4.2'.
Here is a list of system types:
aix, acis, aos, bsd, clix, ctix, dgux, dynix, genix, hpux, isc, linux, luna, lynxos, mach, minix, newsos, osf, osfrose, riscos, sco, solaris, sunos, sysv, ultrix, unos, vms.
You can omit the system type; then `configure' guesses the operating system from the CPU and company.
You can add a version number to the system type; this may or may not make a difference. For example, you can write `bsd4.3' or `bsd4.4' to distinguish versions of BSD. In practice, the version number is most needed for `sysv3' and `sysv4', which are often treated differently.
If you specify an impossible combination such as `i860-dg-vms', then you may get an error message from `configure', or it may ignore part of the information and do the best it can with the rest. `configure' always prints the canonical name for the alternative that it used.
Often a particular model of machine has a name. Many machine names are recognized as aliases for CPU/company combinations. Thus, the machine name `sun3', mentioned above, is an alias for `m68k-sun'. Sometimes we accept a company name as a machine name, when the name is popularly used for a particular machine. Here is a table of the known machine names:
3300, 3b1, 3bn, 7300, altos3068, altos, apollo68, att-7300, balance, convex-cn, crds, decstation-3100, decstation, delta, encore, fx2800, gmicro, hp7nn, hp8nn, hp9k2nn, hp9k3nn, hp9k7nn, hp9k8nn, iris4d, iris, isi68, m3230, magnum, merlin, miniframe, mmax, news-3600, news800, news, next, pbd, pc532, pmax, ps2, risc-news, rtpc, sun2, sun386i, sun386, sun3, sun4, symmetry, tower-32, tower.
Remember that a machine name specifies both the cpu type and the company name.
There are four additional options you can specify independently to describe variant hardware and software configurations. These are `--with-gnu-as', `--with-gnu-ld', `--with-stabs' and `--nfp'.
Using this option does not install GAS. It only modifies the output of GNU CC to work with GAS. Building and installing GAS is up to you.
Conversely, if you do not wish to use GAS and do not specify
`--with-gnu-as' when building GNU CC, it is up to you to make sure
that GAS is not installed. GNU CC searches for a program named
as in various directories; if the program it finds is GAS, then
it runs GAS. If you are not sure where GNU CC finds the assembler it is
using, try specifying `-v' when you run it.
The systems where it makes a difference whether you use GAS are `hppa1.0-any-any', `hppa1.1-any-any', `i386-any-sysv', `i386-any-isc', `i860-any-bsd', `m68k-bull-sysv', `m68k-hp-hpux', `m68k-sony-bsd', `m68k-altos-sysv', `m68000-hp-hpux', `m68000-att-sysv', and `mips-any'). On any other system, `--with-gnu-as' has no effect.
On the systems listed above (except for the HP-PA and for ISC on the 386), if you use GAS, you should also use the GNU linker (and specify `--with-gnu-ld').
This option does not cause the GNU linker to be installed; it just
modifies the behavior of GNU CC to work with the GNU linker.
Specifically, it inhibits the installation of collect2, a program
which otherwise serves as a front-end for the system's linker on most
configurations.
Normally, GNU CC uses the ECOFF debugging format by default; if you prefer BSD stabs, specify `--with-stabs' when you configure GNU CC.
No matter which default you choose when you configure GNU CC, the user can use the `-gcoff' and `-gstabs+' options to specify explicitly the debug format for a particular compilation.
`--with-stabs' is meaningful on the ISC system on the 386, also, if `--with-gas' is used. It selects use of stabs debugging information embedded in COFF output. This kind of debugging information supports C++ well; ordinary COFF debugging information does not.
If you want to install your own homemade configuration files, you can use `local' as the company name to access them. If you use configuration `cpu-local', the configuration name without the cpu prefix is used to form the configuration file names.
Thus, if you specify `m68k-local', configuration uses files `local.md', `local.h', `local.c', `xm-local.h', `t-local', and `x-local', all in the directory `config/m68k'.
Here is a list of configurations that have special treatment or special things you must know:
Objective C and C++ do not yet work on the Alpha. We hope to support C++ in version 2.6.
GNU CC writes a `.verstamp' directive to the assembler output file unless it is built as a cross-compiler. It gets the version to use from the system header file `/usr/include/stamp.h'. If you install a new version of OSF/1, you should rebuild GCC to pick up the new version stamp.
Note that since the Alpha is a 64-bit architecture, cross-compilers from 32-bit machines will not generate as efficient code as that generated when the compiler is running on a 64-bit machine because many optimizations that depend on being able to represent a word on the target in an integral value on the host cannot be performed. Building cross-compilers on the Alpha for 32-bit machines has only been tested in a few cases and may not work properly.
make compare may fail on some versions of OSF/1 unless you add
`-save-temps' to CFLAGS. The same problem occurs on Irix
version 5.1.1. On these systems, the name of the assembler input file
is stored in the object file, and that makes comparison fail if it
differs between the stage1 and stage2 compilations. The
option `-save-temps' forces a fixed name to be used for the
assembler input file, instead of a randomly chosen name in `/tmp'.
GNU CC now supports both the native (ECOFF) debugging format used by DBX and GDB and an encapsulated STABS format for use only with GDB. See the discussion of the `--with-stabs' option of `configure' above for more information on these formats and how to select them.
There is a bug in DEC's assembler that produces incorrect line numbers for ECOFF format when the `.align' directive is used. To work around this problem, GNU CC will not emit such alignment directives even if optimization is being performed if it is writing ECOFF format debugging information. Unfortunately, this has the very undesirable side-effect that code addresses when `-O' is specified are different depending on whether or not `-g' is also specified.
To avoid this behavior, specify `-gstabs+' and use GDB instead of DBX. DEC is now aware of this problem with the assembler and hopes to provide a fix shortly.
You may need to make a variant of the file `a29k.h' for your particular configuration.
mrs@cygnus.com for more details.
law@cs.utah.edu
to get binaries of GNU CC for bootstrapping.
F.Pierresteguy@frcl.bull.fr.
In addition, `--gas' does not currently work with this configuration. Changes in HP-UX have broken the library conversion tool and the linker.
It is best, however, to use an older version of GNU CC for bootstrapping if you have one.
eval `sde-target m88kbcs`
memcpy, memcmp, and memset. If your system lacks
these, you must remove or undo the definition of
TARGET_MEM_FUNCTIONS in `mips-bsd.h'.
alloca
and malloc; you must get the compiled versions of these from GNU
Emacs.
hc, the Metaware compiler, it will work, but you will get
mismatches between the stage 2 and stage 3 compilers in various files.
These errors are minor differences in some floating-point constants and
can be safely ignored; the stage 3 compiler is correct.
The PowerPC and POWER2 architectures are now supported, but have not been extensively tested due to lack of appropriate systems. Only AIX is supported on the PowerPC.
Objective C does not work on this architecture.
XLC version 1.3.0.0 will miscompile `jump.c'. XLC version 1.3.0.1 or later fixes this problem. We do not yet have a PTF number for this fix.
vcc). It produces incorrect code
in some cases (for example, when alloca is used).
Meanwhile, compiling `cp-parse.c' with pcc does not work because of an internal table size limitation in that compiler. To avoid this problem, compile just the GNU C compiler first, and use it to recompile building all the languages that you want to run.
Here we spell out what files will be set up by configure. Normally
you need not be concerned with these files.
The top-level config file is located in the subdirectory `config'. Its name is always `xm-something.h'; usually `xm-machine.h', but there are some exceptions.
If your system does not support symbolic links, you might want to set up `config.h' to contain a `#include' command which refers to the appropriate file.
Unless you have a convention other than `/usr/local' for site-specific files, it is a bad idea to specify `--local-prefix'.
Bison versions older than Sept 8, 1988 will produce incorrect output for `c-parse.c'.
Alternatively, you can do subsequent compilation using a value of the
PATH environment variable such that the necessary GNU tools come
before the standard system tools.
`LANGUAGES=c' specifies that only the C compiler should be compiled. The makefile normally builds compilers for all the supported languages; currently, C, C++ and Objective C. However, C is the only language that is sure to work when you build with other non-GNU C compilers. In addition, building anything but C at this stage is a waste of time.
In general, you can specify the languages to build by typing the argument `LANGUAGES="list"', where list is one or more words from the list `c', `c++', and `objective-c'.
Ignore any warnings you may see about "statement not reached" in `insn-emit.c'; they are normal. Also, warnings about "unknown escape sequence" are normal in `genopinit.c' and perhaps some other files. Any other compilation errors may represent bugs in the port to your machine or operating system, and should be investigated and reported (see section Reporting Bugs).
Some commercial compilers fail to compile GNU CC because they have bugs or limitations. For example, the Microsoft compiler is said to run out of macro space. Some Ultrix compilers run out of expression space; then you need to break up the statement where the problem happens.
If you are building with a previous GNU C compiler, do not use `CC=gcc' on the make command or by editing the Makefile. Instead, use a full pathname to specify the compiler, such as `CC=/usr/local/bin/gcc'. This is because make might execute the `gcc' in the current directory before all of the compiler components have been built.
make stage1
The files are moved into a subdirectory named `stage1'.
Once installation is complete, you may wish to delete these files
with rm -r stage1.
Alternatively, you can do subsequent compilation using a value of the
PATH environment variable such that the necessary GNU tools come
before the standard system tools.
make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O"
This is called making the stage 2 compiler.
The command shown above builds compilers for all the supported
languages. If you don't want them all, you can specify the languages to
build by typing the argument `LANGUAGES="list"'. list
should contain one or more words from the list `c', `c++',
`objective-c', and `proto'. Separate the words with spaces.
`proto' stands for the programs protoize and
unprotoize; they are not a separate language, but you use
LANGUAGES to enable or disable their installation.
If you are going to build the stage 3 compiler, then you might want to build only the C language in stage 2.
Once you have built the stage 2 compiler, if you are short of disk space, you can delete the subdirectory `stage1'.
On a 68000 or 68020 system lacking floating point hardware, unless you have selected a `tm.h' file that expects by default that there is no such hardware, do this instead:
make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O -msoft-float"
make stage2 make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O"
This is called making the stage 3 compiler. Aside from the `-B'
option, the compiler options should be the same as when you made the
stage 2 compiler. But the LANGUAGES option need not be the
same. The command shown above builds compilers for all the supported
languages; if you don't want them all, you can specify the languages to
build by typing the argument `LANGUAGES="list"', as described
above.
Then compare the latest object files with the stage 2 object files--they ought to be identical, aside from time stamps (if any).
On some systems, meaningful comparison of object files is impossible; they always appear "different." This is currently true on Solaris and probably on all systems that use ELF object file format. Some other systems where this is so are listed below.
Use this command to compare the files:
make compare
This will mention any object files that differ between stage 2 and stage 3. Any difference, no matter how innocuous, indicates that the stage 2 compiler has compiled GNU CC incorrectly, and is therefore a potentially serious bug which you should investigate and report (see section Reporting Bugs).
If your system does not put time stamps in the object files, then this is a faster way to compare them (using the Bourne shell):
for file in *.o; do cmp $file stage2/$file done
If you have built the compiler with the `-mno-mips-tfile' option on MIPS machines, you will not be able to compare the files.
The Alpha stores file names of internal temporary files in the object files and `make compare' does not know how to ignore them, so normally you cannot compare on the Alpha. However, if you use the `-save-temps' option when compiling both stage 2 and stage 3, this causes the same file names to be used in both stages; then you can do the comparison.
make objc-runtime CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O"
CC,
CFLAGS and LANGUAGES that you used when compiling the
files that are being installed. One reason this is necessary is that
some versions of Make have bugs and recompile files gratuitously when
you do this step. If you use the same variable values, those files will
be recompiled properly.
For example, if you have built the stage 2 compiler, you can use the following command:
make install CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" LANGUAGES="list"
This copies the files `cc1', `cpp' and `libgcc.a' to files `cc1', `cpp' and `libgcc.a' in the directory `/usr/local/lib/gcc-lib/target/version', which is where the compiler driver program looks for them. Here target is the target machine type specified when you ran `configure', and version is the version number of GNU CC. This naming scheme permits various versions and/or cross-compilers to coexist.
This also copies the driver program `xgcc' into `/usr/local/bin/gcc', so that it appears in typical execution search paths.
On some systems, this command causes recompilation of some files. This
is usually due to bugs in make. You should either ignore this
problem, or use GNU Make.
Warning: there is a bug in alloca in the Sun library. To
avoid this bug, be sure to install the executables of GNU CC that were
compiled by GNU CC. (That is, the executables from stage 2 or 3, not
stage 1.) They use alloca as a built-in function and never the
one in the library.
(It is usually better to install GNU CC executables from stage 2 or 3, since they usually run faster than the ones compiled with some other compiler.)
make install-libobjc CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O"
Go to the previous, next section.