install.texi

早期freebsd实现

@c Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.

@c The text of this file appears in the file INSTALL
@c in the GCC distribution, as well as in the GCC manual.

@ifclear INSTALLONLY
@node Installation
@chapter Installing GNU CC
@end ifclear
@cindex installing GNU CC

Here is the procedure for installing GNU CC on a Unix system.

@menu
* Other Dir::     Compiling in a separate directory (not where the source is).
* Cross-Compiler::   Building and installing a cross-compiler.
* PA Install::    See below for installation on the HP Precision Architecture.
* Sun Install::   See below for installation on the Sun.
* 3b1 Install::   See below for installation on the 3b1.
* Unos Install::  See below for installation on Unos (from CRDS).
* VMS Install::   See below for installation on VMS.
* WE32K Install:: See below for installation on the 3b* aside from the 3b1.
* MIPS Install::  See below for installation on the MIPS Architecture.
@end menu
@iftex
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.
@end iftex

@enumerate
@item
If you have built GNU CC previously in the same directory for a
different target machine, do @samp{make distclean} to delete all files
that might be invalid.  One of the files this deletes is
@file{Makefile}; if @samp{make distclean} complains that @file{Makefile}
does not exist, it probably means that the directory is already suitably
clean.

@item
On a System V release 4 system, make sure @file{/usr/bin} precedes
@file{/usr/ucb} in @code{PATH}.  The @code{cc} command in
@file{/usr/ucb} uses libraries which have bugs.

@item
Specify the host and target machine configurations.  You do this by
running the file @file{configure} with appropriate arguments.

If you are building a compiler to produce code for the machine it runs
on, specify just one machine type.  Use the @samp{--target} option; the
host type will default to be the same as the target.  (For information
on building a cross-compiler, see @ref{Cross-Compiler}.)  The command
looks like this:

@example
configure --target=sparc-sun-sunos4.1
@end example

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: @samp{@var{cpu}-@var{company}-@var{system}}.
(The three parts may themselves contain dashes; @file{configure}
can figure out which dashes serve which purpose.)  For example,
@samp{m68k-sun-sunos4.1} specifies a Sun 3.

You can also replace parts of the configuration by nicknames or aliases.
For example, @samp{sun3} stands for @samp{m68k-sun}, so
@samp{sun3-sunos4.1} is another way to specify a Sun 3.  You can also
use simply @samp{sun3-sunos}, since the version of SunOS is assumed by
default to be version 4.  @samp{sun3-bsd} also works, since
@file{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:

@quotation
@c gmicro, alliant, spur and tahoe omitted since they don't work.
a29k, alpha, arm, c@var{n}, elxsi, hppa1.0, hppa1.1,
i386, i860, i960, m68000, m68k, m88k, mips,
ns32k, pyramid, romp, rs6000, sparc, vax, we32k.
@end quotation

Here are the recognized company names.  As you can see, customary
abbreviations are used rather than the longer official names.

@quotation
alliant, altos, apollo, att,
cbm, convergent, convex, crds, dec, dg,
encore, harris, hp, ibm, mips,
motorola, ncr, next, ns, omron,
sequent, sgi, sony, sun, tti, unicom.
@end quotation

The company name is meaningful only to disambiguate when the rest of
the information supplied is insufficient.  You can omit it, writing
just @samp{@var{cpu}-@var{system}}, if it is not needed.  For example,
@samp{vax-ultrix4.2} is equivalent to @samp{vax-dec-ultrix4.2}.

Here is a list of system types:

@quotation
aix, aos, bsd, ctix, dgux, dynix,
genix, hpux, isc, linux, luna, mach,
minix, newsos, osf, osfrose, riscos,
sco, sunos, sysv, ultrix, unos, vms.
@end quotation

@noindent
You can omit the system type; then @file{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 @samp{bsd4.3} or
@samp{bsd4.4} to distinguish versions of BSD.  In practice, the version
number is most needed for @samp{sysv3} and @samp{sysv4}, which are often
treated differently.

If you specify an impossible combination such as @samp{i860-dg-vms},
then you may get an error message from @file{configure}, or it may
ignore part of the information and do the best it can with the rest.
@file{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 @samp{sun3}, mentioned above, is an alias for @samp{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:

@quotation
3300, 3b1, 3b@var{n}, 7300, altos3068, altos,
apollo68, att-7300, balance,
convex-c@var{n}, crds, decstation-3100,
decstation, delta, encore,
fx2800, gmicro, hp7@var{nn}, hp8@var{nn},
hp9k2@var{nn}, hp9k3@var{nn}, hp9k7@var{nn},
hp9k8@var{nn}, 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.
@end quotation 

@noindent
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
@samp{--with-gnu-as}, @samp{--with-gnu-ld}, @samp{--with-stabs} and
@samp{--nfp}.

@table @samp
@item --with-gnu-as
On certain systems, you must specify whether you want GNU CC to work
with the usual compilation tools or with the GNU compilation tools
(including GAS).  Use the @samp{--with-gnu-as} argument when you run
@file{configure}, if you want to use the GNU tools.  (Specify
@samp{--with-gnu-ld} as well, since on these systems GAS works only with
the GNU linker.)  The systems where this makes a difference are
@samp{i386-@var{anything}-sysv}, @samp{i860-@var{anything}-bsd},
@samp{m68k-hp-hpux}, @samp{m68k-sony-bsd}, @samp{m68k-altos-sysv},
@samp{m68000-hp-hpux}, and @samp{m68000-att-sysv}.  On any other system,
@samp{--with-gnu-as} has no effect.

@item --with-gnu-ld
Specify the option @samp{--with-gnu-ld} if you plan to use the GNU
linker.  This inhibits the installation of @code{collect2}, a program
which otherwise serves as a front-end for the system's linker on most
configurations.

@item --with-stabs
On MIPS based systems, you must specify whether you want GNU CC to
create the normal ECOFF debugging format, or to use BSD-style stabs
passed through the ECOFF symbol table.  The normal ECOFF debug format
cannot fully handle languages other than C.  BSD stabs format can handle
other languages, but it only works with the GNU debugger GDB.

Normally, GNU CC uses the ECOFF debugging format by default; if you
prefer BSD stabs, specify @samp{--with-stabs} when you configure GNU
CC.

No matter which default you choose when you configure GNU CC, the user
can use the @samp{-gcoff} and @samp{-gstabs+} options to specify explicitly
the debug format for a particular compilation.

@item --nfp
On certain systems, you must specify whether the machine has a floating
point unit.  These systems are @samp{m68k-sun-sunos@var{n}} and
@samp{m68k-isi-bsd}.  On any other system, @samp{--nfp} currently has no
effect, though perhaps there are other systems where it could usefully
make a difference.
@end table

If you want to install your own homemade configuration files, you can
use @samp{local} as the company name to access them.  If you use 
configuration @samp{@var{cpu}-local}, the entire configuration name
is used to form the configuration file names.

Thus, if you specify @samp{m68k-local}, then the files used are
@file{m68k-local.md}, @file{m68k-local.h}, @file{m68k-local.c},
@file{xm-m68k-local.h}, @file{t-m68k-local}, and @file{x-m68k-local}.

Here is a list of configurations that have special treatment or special
things you must know:

@table @samp
@item alpha-*-osf1
Systems using processors that implement the DEC Alpha architecture and
are running the OSF/1 operating system. (VMS on the Alpha is not
currently supported by GNU CC.)  As of this writing, the only Alpha-based
product currently available from DEC is the 21064 (EV4) processor chip;
no system-level products can be ordered.  This port is provided for
those developers who might have early Alpha hardware from DEC or other
vendors and run the OSF/1 operating system.  It has not been extensively
tested and both the C++ and Objective-C languages may not work, except
in a cross-compilation environment.

The @code{ASSEMBLE_FILE_START} macro writes a @code{.verstamp} directive
containing the version of the calling sequence.  Currently, we use
@samp{9 0}, which we believe will work until the official release by DEC
of their system, at which point @samp{3 11} is the correct value.  If
you get a mismatch error from the assembler on a @code{.verstamp} line,
consult the file @file{/usr/include/stamp.h} for the present value.  GNU
C on the Alpha does not support versions of DEC's OSF/1 earlier than
BL9; if you are running an older version, we suggest you ask your DEC
contact for an update.

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.

@item a29k
AMD Am29K-family processors.  These are normally used in embedded
applications.  There are no standard Unix configurations.
This configuration
corresponds to AMD's standard calling sequence and binary interface
and is compatible with other 29K tools.  

You may need to make a variant of the file @file{a29k.h} for your
particular configuration.

@item a29k-*-bsd
AMD Am29050 used in a system running a variant of BSD Unix.

@item elxsi-elxsi-bsd
The Elxsi's C compiler has known limitations that prevent it from
compiling GNU C.  Please contact @code{mrs@@cygnus.com} for more details.

@ignore
@item fx80
Alliant FX/8 computer.  Note that the standard installed C compiler in
Concentrix 5.0 has a bug which prevent it from compiling GNU CC
correctly.  You can patch the compiler bug as follows:

@example
cp /bin/pcc ./pcc
adb -w ./pcc - << EOF
15f6?w 6610
EOF
@end example

Then you must use the @samp{-ip12} option when compiling GNU CC
with the patched compiler, as shown here:

@example
make CC="./pcc -ip12" CFLAGS=-w
@end example

Note also that Alliant's version of DBX does not manage to work with the
output from GNU CC.
@end ignore

@item i386-*-sco
Compilation with RCC is recommended.

@item i386-ibm-aix
You need a version of GAS that you can get from @code{tranle@@intellicorp.com}.

@item i386-sequent
Go to the Berkeley universe before compiling.  In addition, you probably
need to create a file named @file{string.h} containing just one line:
@samp{#include <strings.h>}.

@item i386-sun-sunos4
You may find that you need another version of GNU CC to begin
bootstrapping with, since the current version when built with the
system's own compiler seems to get an infinite loop compiling part of
@file{libgcc2.c}.  GNU CC version 2 compiled with GNU CC (any version)
seems not to have this problem.

@item m68000-att
AT&T 3b1, a.k.a. 7300 PC.  Special procedures are needed to compile GNU
CC with this machine's standard C compiler, due to bugs in that
compiler.  @xref{3b1 Install}.  You can bootstrap it more easily with
previous versions of GNU CC if you have them.

@item m68000-hp-bsd
HP 9000 series 200 running BSD.  Note that the C compiler that comes
with this system cannot compile GNU CC; contact @code{law@@cs.utah.edu}
to get binaries of GNU CC for bootstrapping.

@item m68k-altos
Altos 3068.  You must use the GNU assembler, linker and debugger, with
COFF-encapsulation.  Also, you must fix a kernel bug.  Details in the
file @file{README.ALTOS}.

@item m68k-hp-hpux
HP 9000 series 300 or 400 running HP-UX.  HP-UX version 8.0 has a bug in
the assembler that prevents compilation of GNU CC.  To fix it, get patch
PHCO_0800 from HP.

In addition, @samp{--gas} does not currently work with this
configuration.  Changes in HP-UX have broken the library conversion tool
and the linker.

@item m68k-sun
Sun 3.  We do not provide a configuration file to use the Sun FPA by
default, because programs that establish signal handlers for floating
point traps inherently cannot work with the FPA.

@item m88k-svr3
Motorola m88k running the AT&T/Unisoft/Motorola V.3 reference port.
These systems tend to use the Green Hills C, revision 1.8.5, as the
standard C compiler.  There are apparently bugs in this compiler that
result in object files differences between stage 2 and stage 3.  If this
happens, make the stage 4 compiler and compare it to the stage 3
compiler.  If the stage 3 and stage 4 object files are identical, this
suggests a problem with the standard C compiler.  It is best, however,
to use an older version of GNU CC for bootstrapping.

@item m88k-dgux