install.texi

理解和实践操作系统的一本好书

@end table


@heading Tools/packages necessary for modifying GCC
@table @asis
@item autoconf version 2.59
@itemx GNU m4 version 1.4 (or later)

Necessary when modifying @file{configure.ac}, @file{aclocal.m4}, etc.@:
to regenerate @file{configure} and @file{config.in} files.

@item automake version 1.9.6

Necessary when modifying a @file{Makefile.am} file to regenerate its
associated @file{Makefile.in}.

Much of GCC does not use automake, so directly edit the @file{Makefile.in}
file.  Specifically this applies to the @file{gcc}, @file{intl},
@file{libcpp}, @file{libiberty}, @file{libobjc} directories as well
as any of their subdirectories.

For directories that use automake, GCC requires the latest release in
the 1.9.x series, which is currently 1.9.6.  When regenerating a directory
to a newer version, please update all the directories using an older 1.9.x
to the latest released version.

@item gettext version 0.14.5 (or later)

Needed to regenerate @file{gcc.pot}.

@item gperf version 2.7.2 (or later)

Necessary when modifying @command{gperf} input files, e.g.@:
@file{gcc/cp/cfns.gperf} to regenerate its associated header file, e.g.@:
@file{gcc/cp/cfns.h}.

@item DejaGnu 1.4.4
@itemx Expect
@itemx Tcl

Necessary to run the GCC testsuite; see the section on testing for details.

@item autogen version 5.5.4 (or later) and
@itemx guile version 1.4.1 (or later)

Necessary to regenerate @file{fixinc/fixincl.x} from
@file{fixinc/inclhack.def} and @file{fixinc/*.tpl}.

Necessary to run @samp{make check} for @file{fixinc}.

Necessary to regenerate the top level @file{Makefile.in} file from
@file{Makefile.tpl} and @file{Makefile.def}.

@item GNU Bison version 1.28 (or later)

Necessary when modifying @file{*.y} files.  Necessary to build the
@code{treelang} front end (which is not enabled by default) from a
checkout of the SVN repository; the generated files are not in the
repository.  They are included in releases.

Berkeley @command{yacc} (@command{byacc}) has been reported to work
as well.

@item Flex version 2.5.4 (or later)

Necessary when modifying @file{*.l} files.

Necessary to build GCC during development because the generated output
files are not included in the SVN repository.  They are included in
releases.

@item Texinfo version 4.4 (or later)

Necessary for running @command{makeinfo} when modifying @file{*.texi}
files to test your changes.

Necessary for running @command{make dvi} or @command{make pdf} to
create printable documentation in DVI or PDF format.  Texinfo version
4.8 or later is required for @command{make pdf}.

Necessary to build GCC documentation during development because the
generated output files are not included in the SVN repository.  They are
included in releases.

@item @TeX{} (any working version)

Necessary for running @command{texi2dvi} and @command{texi2pdf}, which 
are used when running @command{make dvi} or @command{make pdf} to create
DVI or PDF files, respectively.

@item SVN (any version)
@itemx SSH (any version)

Necessary to access the SVN repository.  Public releases and weekly
snapshots of the development sources are also available via FTP@.

@item Perl version 5.6.1 (or later)

Necessary when regenerating @file{Makefile} dependencies in libiberty.
Necessary when regenerating @file{libiberty/functions.texi}.
Necessary when generating manpages from Texinfo manuals.
Necessary when targetting Darwin, building libstdc++,
and not using @option{--disable-symvers}.
Used by various scripts to generate some files included in SVN (mainly
Unicode-related and rarely changing) from source tables.

@item GNU diffutils version 2.7 (or later)

Useful when submitting patches for the GCC source code.

@item patch version 2.5.4 (or later)

Necessary when applying patches, created with @command{diff}, to one's
own sources.

@item ecj1
@itemx gjavah

If you wish to modify @file{.java} files in libjava, you will need to
configure with @option{--enable-java-maintainer-mode}, and you will need
to have executables named @command{ecj1} and @command{gjavah} in your path.
The @command{ecj1} executable should run the Eclipse Java compiler via
the GCC-specific entry point.  You can download a suitable jar from
@uref{ftp://sourceware.org/pub/java/}, or by running the script
@command{contrib/download_ecj}.

@end table

@html
<hr />
<p>
@end html
@ifhtml
@uref{./index.html,,Return to the GCC Installation page}
@end ifhtml
@end ifset

@c ***Downloading the source**************************************************
@ifnothtml
@comment node-name,     next,          previous, up
@node    Downloading the source, Configuration, Prerequisites, Installing GCC
@end ifnothtml
@ifset downloadhtml
@ifnothtml
@chapter Downloading GCC
@end ifnothtml
@cindex Downloading GCC
@cindex Downloading the Source

GCC is distributed via @uref{http://gcc.gnu.org/svn.html,,SVN} and FTP
tarballs compressed with @command{gzip} or
@command{bzip2}.  It is possible to download a full distribution or specific
components.

Please refer to the @uref{http://gcc.gnu.org/releases.html,,releases web page}
for information on how to obtain GCC@.

The full distribution includes the C, C++, Objective-C, Fortran, Java,
and Ada (in the case of GCC 3.1 and later) compilers.  The full
distribution also includes runtime libraries for C++, Objective-C,
Fortran, and Java.  In GCC 3.0 and later versions, the GNU compiler
testsuites are also included in the full distribution.

If you choose to download specific components, you must download the core
GCC distribution plus any language specific distributions you wish to
use.  The core distribution includes the C language front end as well as the
shared components.  Each language has a tarball which includes the language
front end as well as the language runtime (when appropriate).

Unpack the core distribution as well as any language specific
distributions in the same directory.

If you also intend to build binutils (either to upgrade an existing
installation or for use in place of the corresponding tools of your
OS), unpack the binutils distribution either in the same directory or
a separate one.  In the latter case, add symbolic links to any
components of the binutils you intend to build alongside the compiler
(@file{bfd}, @file{binutils}, @file{gas}, @file{gprof}, @file{ld},
@file{opcodes}, @dots{}) to the directory containing the GCC sources.

@html
<hr />
<p>
@end html
@ifhtml
@uref{./index.html,,Return to the GCC Installation page}
@end ifhtml
@end ifset

@c ***Configuration***********************************************************
@ifnothtml
@comment node-name,     next,          previous, up
@node    Configuration, Building, Downloading the source, Installing GCC
@end ifnothtml
@ifset configurehtml
@ifnothtml
@chapter Installing GCC: Configuration
@end ifnothtml
@cindex Configuration
@cindex Installing GCC: Configuration

Like most GNU software, GCC must be configured before it can be built.
This document describes the recommended configuration procedure
for both native and cross targets.

We use @var{srcdir} to refer to the toplevel source directory for
GCC; we use @var{objdir} to refer to the toplevel build/object directory.

If you obtained the sources via SVN, @var{srcdir} must refer to the top
@file{gcc} directory, the one where the @file{MAINTAINERS} can be found,
and not its @file{gcc} subdirectory, otherwise the build will fail.

If either @var{srcdir} or @var{objdir} is located on an automounted NFS
file system, the shell's built-in @command{pwd} command will return
temporary pathnames.  Using these can lead to various sorts of build
problems.  To avoid this issue, set the @env{PWDCMD} environment
variable to an automounter-aware @command{pwd} command, e.g.,
@command{pawd} or @samp{amq -w}, during the configuration and build
phases.

First, we @strong{highly} recommend that GCC be built into a
separate directory than the sources which does @strong{not} reside
within the source tree.  This is how we generally build GCC; building
where @var{srcdir} == @var{objdir} should still work, but doesn't
get extensive testing; building where @var{objdir} is a subdirectory
of @var{srcdir} is unsupported.

If you have previously built GCC 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
or issues a message like ``don't know how to make distclean'' it probably
means that the directory is already suitably clean.  However, with the
recommended method of building in a separate @var{objdir}, you should
simply use a different @var{objdir} for each target.

Second, when configuring a native system, either @command{cc} or
@command{gcc} must be in your path or you must set @env{CC} in
your environment before running configure.  Otherwise the configuration
scripts may fail.

@ignore
Note that the bootstrap compiler and the resulting GCC must be link
compatible, else the bootstrap will fail with linker errors about
incompatible object file formats.  Several multilibed targets are
affected by this requirement, see
@ifnothtml
@ref{Specific, host/target specific installation notes}.
@end ifnothtml
@ifhtml
@uref{specific.html,,host/target specific installation notes}.
@end ifhtml
@end ignore

To configure GCC:

@smallexample
   % mkdir @var{objdir}
   % cd @var{objdir}
   % @var{srcdir}/configure [@var{options}] [@var{target}]
@end smallexample

@heading Distributor options

If you will be distributing binary versions of GCC, with modifications
to the source code, you should use the options described in this
section to make clear that your version contains modifications.

@table @code
@item --with-pkgversion=@var{version}
Specify a string that identifies your package.  You may wish
to include a build number or build date.  This version string will be
included in the output of @command{gcc --version}.  This suffix does
not replace the default version string, only the @samp{GCC} part.

The default value is @samp{GCC}.

@item --with-bugurl=@var{url}
Specify the URL that users should visit if they wish to report a bug.
You are of course welcome to forward bugs reported to you to the FSF,
if you determine that they are not bugs in your modifications.

The default value refers to the FSF's GCC bug tracker.

@end table

@heading Target specification
@itemize @bullet
@item
GCC has code to correctly determine the correct value for @var{target}
for nearly all native systems.  Therefore, we highly recommend you not
provide a configure target when configuring a native compiler.

@item
@var{target} must be specified as @option{--target=@var{target}}
when configuring a cross compiler; examples of valid targets would be
m68k-coff, sh-elf, etc.

@item
Specifying just @var{target} instead of @option{--target=@var{target}}
implies that the host defaults to @var{target}.
@end itemize


@heading Options specification

Use @var{options} to override several configure time options for
GCC@.  A list of supported @var{options} follows; @samp{configure
--help} may list other options, but those not listed below may not
work and should not normally be used.

Note that each @option{--enable} option has a corresponding
@option{--disable} option and that each @option{--with} option has a
corresponding @option{--without} option.

@table @code
@item --prefix=@var{dirname}
Specify the toplevel installation
directory.  This is the recommended way to install the tools into a directory
other than the default.  The toplevel installation directory defaults to
@file{/usr/local}.

We @strong{highly} recommend against @var{dirname} being the same or a
subdirectory of @var{objdir} or vice versa.  If specifying a directory
beneath a user's home directory tree, some shells will not expand