CbC/CbC_gcc: gcc/doc/install.texi comparison

comparison gcc/doc/install.texi @ 0:a06113de4d67

first commit

author	kent <kent@cr.ie.u-ryukyu.ac.jp>
date	Fri, 17 Jul 2009 14:47:48 +0900
parents
children	855418dad1a3

comparison

equal deleted inserted replaced

--1:000000000000
+:a06113de4d67
+\input texinfo.tex    @c -*-texinfo-*-
+@c @ifnothtml
+@c %**start of header
+@setfilename gccinstall.info
+@settitle Installing GCC
+@setchapternewpage odd
+@c %**end of header
+@c @end ifnothtml
+@include gcc-common.texi
+@c Specify title for specific html page
+@ifset indexhtml
+@settitle Installing GCC
+@end ifset
+@ifset specifichtml
+@settitle Host/Target specific installation notes for GCC
+@end ifset
+@ifset prerequisiteshtml
+@settitle Prerequisites for GCC
+@end ifset
+@ifset downloadhtml
+@settitle Downloading GCC
+@end ifset
+@ifset configurehtml
+@settitle Installing GCC: Configuration
+@end ifset
+@ifset buildhtml
+@settitle Installing GCC: Building
+@end ifset
+@ifset testhtml
+@settitle Installing GCC: Testing
+@end ifset
+@ifset finalinstallhtml
+@settitle Installing GCC: Final installation
+@end ifset
+@ifset binarieshtml
+@settitle Installing GCC: Binaries
+@end ifset
+@ifset oldhtml
+@settitle Installing GCC: Old documentation
+@end ifset
+@ifset gfdlhtml
+@settitle Installing GCC: GNU Free Documentation License
+@end ifset
+@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+@c 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+@c *** Converted to texinfo by Dean Wakerley, dean@wakerley.com
+@c IMPORTANT: whenever you modify this file, run `install.texi2html' to
+@c test the generation of HTML documents for the gcc.gnu.org web pages.
+@c
+@c Do not use @footnote{} in this file as it breaks install.texi2html!
+@c Include everything if we're not making html
+@ifnothtml
+@set indexhtml
+@set specifichtml
+@set prerequisiteshtml
+@set downloadhtml
+@set configurehtml
+@set buildhtml
+@set testhtml
+@set finalinstallhtml
+@set binarieshtml
+@set oldhtml
+@set gfdlhtml
+@end ifnothtml
+@c Part 2 Summary Description and Copyright
+@copying
+Copyright @copyright{} 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997,
+1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
+2008 Free Software Foundation, Inc.
+@sp 1
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no
+Invariant Sections, the Front-Cover texts being (a) (see below), and
+with the Back-Cover Texts being (b) (see below).  A copy of the
+license is included in the section entitled ``@uref{./gfdl.html,,GNU
+Free Documentation License}''.
+(a) The FSF's Front-Cover Text is:
+A GNU Manual
+(b) The FSF's Back-Cover Text is:
+You have freedom to copy and modify this GNU Manual, like GNU
+software.  Copies published by the Free Software Foundation raise
+funds for GNU development.
+@end copying
+@ifinfo
+@insertcopying
+@end ifinfo
+@dircategory Software development
+@direntry
+* gccinstall: (gccinstall).    Installing the GNU Compiler Collection.
+@end direntry
+@c Part 3 Titlepage and Copyright
+@titlepage
+@title Installing GCC
+@versionsubtitle
+@c The following two commands start the copyright page.
+@page
+@vskip 0pt plus 1filll
+@insertcopying
+@end titlepage
+@c Part 4 Top node, Master Menu, and/or Table of Contents
+@ifinfo
+@node    Top, , , (dir)
+@comment node-name, next,          Previous, up
+@menu
+* Installing GCC::  This document describes the generic installation
+procedure for GCC as well as detailing some target
+specific installation instructions.
+* Specific::        Host/target specific installation notes for GCC.
+* Binaries::        Where to get pre-compiled binaries.
+* Old::             Old installation documentation.
+* GNU Free Documentation License:: How you can copy and share this manual.
+* Concept Index::   This index has two entries.
+@end menu
+@end ifinfo
+@iftex
+@contents
+@end iftex
+@c Part 5 The Body of the Document
+@c ***Installing GCC**********************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Installing GCC, Binaries, , Top
+@end ifnothtml
+@ifset indexhtml
+@ifnothtml
+@chapter Installing GCC
+@end ifnothtml
+The latest version of this document is always available at
+@uref{http://gcc.gnu.org/install/,,http://gcc.gnu.org/install/}.
+This document describes the generic installation procedure for GCC as well
+as detailing some target specific installation instructions.
+GCC includes several components that previously were separate distributions
+with their own installation instructions.  This document supersedes all
+package specific installation instructions.
+@emph{Before} starting the build/install procedure please check the
+@ifnothtml
+@ref{Specific, host/target specific installation notes}.
+@end ifnothtml
+@ifhtml
+@uref{specific.html,,host/target specific installation notes}.
+@end ifhtml
+We recommend you browse the entire generic installation instructions before
+you proceed.
+Lists of successful builds for released versions of GCC are
+available at @uref{http://gcc.gnu.org/buildstat.html}.
+These lists are updated as new information becomes available.
+The installation procedure itself is broken into five steps.
+@ifinfo
+@menu
+* Prerequisites::
+* Downloading the source::
+* Configuration::
+* Building::
+* Testing:: (optional)
+* Final install::
+@end menu
+@end ifinfo
+@ifhtml
+@enumerate
+@item
+@uref{prerequisites.html,,Prerequisites}
+@item
+@uref{download.html,,Downloading the source}
+@item
+@uref{configure.html,,Configuration}
+@item
+@uref{build.html,,Building}
+@item
+@uref{test.html,,Testing} (optional)
+@item
+@uref{finalinstall.html,,Final install}
+@end enumerate
+@end ifhtml
+Please note that GCC does not support @samp{make uninstall} and probably
+won't do so in the near future as this would open a can of worms.  Instead,
+we suggest that you install GCC into a directory of its own and simply
+remove that directory when you do not need that specific version of GCC
+any longer, and, if shared libraries are installed there as well, no
+more binaries exist that use them.
+@ifhtml
+There are also some @uref{old.html,,old installation instructions},
+which are mostly obsolete but still contain some information which has
+not yet been merged into the main part of this manual.
+@end ifhtml
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@insertcopying
+@end ifhtml
+@end ifset
+@c ***Prerequisites**************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Prerequisites, Downloading the source, , Installing GCC
+@end ifnothtml
+@ifset prerequisiteshtml
+@ifnothtml
+@chapter Prerequisites
+@end ifnothtml
+@cindex Prerequisites
+GCC requires that various tools and packages be available for use in the
+build procedure.  Modifying GCC sources requires additional tools
+described below.
+@heading Tools/packages necessary for building GCC
+@table @asis
+@item ISO C90 compiler
+Necessary to bootstrap GCC, although versions of GCC prior
+to 3.4 also allow bootstrapping with a traditional (K&R) C compiler.
+To build all languages in a cross-compiler or other configuration where
+3-stage bootstrap is not performed, you need to start with an existing
+GCC binary (version 2.95 or later) because source code for language
+frontends other than C might use GCC extensions.
+@item GNAT
+In order to build the Ada compiler (GNAT) you must already have GNAT
+installed because portions of the Ada frontend are written in Ada (with
+GNAT extensions.)  Refer to the Ada installation instructions for more
+specific information.
+@item A ``working'' POSIX compatible shell, or GNU bash
+Necessary when running @command{configure} because some
+@command{/bin/sh} shells have bugs and may crash when configuring the
+target libraries.  In other cases, @command{/bin/sh} or @command{ksh}
+have disastrous corner-case performance problems.  This
+can cause target @command{configure} runs to literally take days to
+complete in some cases.
+So on some platforms @command{/bin/ksh} is sufficient, on others it
+isn't.  See the host/target specific instructions for your platform, or
+use @command{bash} to be sure.  Then set @env{CONFIG_SHELL} in your
+environment to your ``good'' shell prior to running
+@command{configure}/@command{make}.
+@command{zsh} is not a fully compliant POSIX shell and will not
+work when configuring GCC@.
+@item A POSIX or SVR4 awk
+Necessary for creating some of the generated source files for GCC@.
+If in doubt, use a recent GNU awk version, as some of the older ones
+are broken.  GNU awk version 3.1.5 is known to work.
+@item GNU binutils
+Necessary in some circumstances, optional in others.  See the
+host/target specific instructions for your platform for the exact
+requirements.
+@item gzip version 1.2.4 (or later) or
+@itemx bzip2 version 1.0.2 (or later)
+Necessary to uncompress GCC @command{tar} files when source code is
+obtained via FTP mirror sites.
+@item GNU make version 3.80 (or later)
+You must have GNU make installed to build GCC@.
+@item GNU tar version 1.14 (or later)
+Necessary (only on some platforms) to untar the source code.  Many
+systems' @command{tar} programs will also work, only try GNU
+@command{tar} if you have problems.
+@item GNU Multiple Precision Library (GMP) version 4.1 (or later)
+Necessary to build GCC@.  If you do not have it installed in your
+library search path, you will have to configure with the
+@option{--with-gmp} configure option.  See also @option{--with-gmp-lib}
+and @option{--with-gmp-include}.  Alternatively, if a GMP source
+distribution is found in a subdirectory of your GCC sources named
+@file{gmp}, it will be built together with GCC@.
+@item MPFR Library version 2.3.2 (or later)
+Necessary to build GCC@.  It can be downloaded from
+@uref{http://www.mpfr.org/}.  The version of MPFR that is bundled with
+GMP 4.1.x contains numerous bugs.  Although GCC may appear to function
+with the buggy versions of MPFR, there are a few bugs that will not be
+fixed when using this version.  It is strongly recommended to upgrade
+to the recommended version of MPFR.
+The @option{--with-mpfr} configure option should be used if your MPFR
+Library is not installed in your default library search path.  See also
+@option{--with-mpfr-lib} and @option{--with-mpfr-include}.
+Alternatively, if a MPFR source distribution is found in a subdirectory
+of your GCC sources named @file{mpfr}, it will be built together with
+GCC@.
+@item Parma Polyhedra Library (PPL) version 0.10
+Necessary to build GCC with the Graphite loop optimizations.
+It can be downloaded from @uref{http://www.cs.unipr.it/ppl/Download/}.
+The @option{--with-ppl} configure option should be used if PPL is not
+installed in your default library search path.
+@item CLooG-PPL version 0.15
+Necessary to build GCC with the Graphite loop optimizations.  It can
+be downloaded from @uref{ftp://gcc.gnu.org/pub/gcc/infrastructure/}.
+The code in @file{cloog-ppl-0.15.tar.gz} comes from a branch of CLooG
+available from @uref{http://repo.or.cz/w/cloog-ppl.git}.  CLooG-PPL
+should be configured with @option{--with-ppl}.
+The @option{--with-cloog} configure option should be used if CLooG is
+not installed in your default library search path.
+@item @command{jar}, or InfoZIP (@command{zip} and @command{unzip})
+Necessary to build libgcj, the GCJ runtime.
+@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 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.7 (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}.
+@item antlr.jar version 2.7.1 (or later)
+@itemx antlr binary
+If you wish to build the @command{gjdoc} binary in libjava, you will
+need to have a @file{antlr.jar} library available. The library is
+searched in system locations but can be configured with
+@option{--with-antlr-jar=} instead.  When configuring with
+@option{--enable-java-maintainer-mode}, you will need to have one of
+the executables named @command{cantlr}, @command{runantlr} or
+@command{antlr} in your path.
+@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.
+Likewise, the GMP and MPFR libraries can be automatically built together
+with GCC.  Unpack the GMP and/or MPFR source distributions in the
+directory containing the GCC sources and rename their directories to
+@file{gmp} and @file{mpfr}, respectively (or use symbolic links with the
+same name).
+@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
+@var{dirname} correctly if it contains the @samp{~} metacharacter; use
+@env{$HOME} instead.
+The following standard @command{autoconf} options are supported.  Normally you
+should not need to use these options.
+@table @code
+@item --exec-prefix=@var{dirname}
+Specify the toplevel installation directory for architecture-dependent
+files.  The default is @file{@var{prefix}}.
+@item --bindir=@var{dirname}
+Specify the installation directory for the executables called by users
+(such as @command{gcc} and @command{g++}).  The default is
+@file{@var{exec-prefix}/bin}.
+@item --libdir=@var{dirname}
+Specify the installation directory for object code libraries and
+internal data files of GCC@.  The default is @file{@var{exec-prefix}/lib}.
+@item --libexecdir=@var{dirname}
+Specify the installation directory for internal executables of GCC@.
+The default is @file{@var{exec-prefix}/libexec}.
+@item --with-slibdir=@var{dirname}
+Specify the installation directory for the shared libgcc library.  The
+default is @file{@var{libdir}}.
+@item --infodir=@var{dirname}
+Specify the installation directory for documentation in info format.
+The default is @file{@var{prefix}/info}.
+@item --datadir=@var{dirname}
+Specify the installation directory for some architecture-independent
+data files referenced by GCC@.  The default is @file{@var{prefix}/share}.
+@item --mandir=@var{dirname}
+Specify the installation directory for manual pages.  The default is
+@file{@var{prefix}/man}.  (Note that the manual pages are only extracts from
+the full GCC manuals, which are provided in Texinfo format.  The manpages
+are derived by an automatic conversion process from parts of the full
+manual.)
+@item --with-gxx-include-dir=@var{dirname}
+Specify
+the installation directory for G++ header files.  The default is
+@file{@var{prefix}/include/c++/@var{version}}.
+@end table
+@item --program-prefix=@var{prefix}
+GCC supports some transformations of the names of its programs when
+installing them.  This option prepends @var{prefix} to the names of
+programs to install in @var{bindir} (see above).  For example, specifying
+@option{--program-prefix=foo-} would result in @samp{gcc}
+being installed as @file{/usr/local/bin/foo-gcc}.
+@item --program-suffix=@var{suffix}
+Appends @var{suffix} to the names of programs to install in @var{bindir}
+(see above).  For example, specifying @option{--program-suffix=-3.1}
+would result in @samp{gcc} being installed as
+@file{/usr/local/bin/gcc-3.1}.
+@item --program-transform-name=@var{pattern}
+Applies the @samp{sed} script @var{pattern} to be applied to the names
+of programs to install in @var{bindir} (see above).  @var{pattern} has to
+consist of one or more basic @samp{sed} editing commands, separated by
+semicolons.  For example, if you want the @samp{gcc} program name to be
+transformed to the installed program @file{/usr/local/bin/myowngcc} and
+the @samp{g++} program name to be transformed to
+@file{/usr/local/bin/gspecial++} without changing other program names,
+you could use the pattern
+@option{--program-transform-name='s/^gcc$/myowngcc/; s/^g++$/gspecial++/'}
+to achieve this effect.
+All three options can be combined and used together, resulting in more
+complex conversion patterns.  As a basic rule, @var{prefix} (and
+@var{suffix}) are prepended (appended) before further transformations
+can happen with a special transformation script @var{pattern}.
+As currently implemented, this option only takes effect for native
+builds; cross compiler binaries' names are not transformed even when a
+transformation is explicitly asked for by one of these options.
+For native builds, some of the installed programs are also installed
+with the target alias in front of their name, as in
+@samp{i686-pc-linux-gnu-gcc}.  All of the above transformations happen
+before the target alias is prepended to the name---so, specifying
+@option{--program-prefix=foo-} and @option{program-suffix=-3.1}, the
+resulting binary would be installed as
+@file{/usr/local/bin/i686-pc-linux-gnu-foo-gcc-3.1}.
+As a last shortcoming, none of the installed Ada programs are
+transformed yet, which will be fixed in some time.
+@item --with-local-prefix=@var{dirname}
+Specify the
+installation directory for local include files.  The default is
+@file{/usr/local}.  Specify this option if you want the compiler to
+search directory @file{@var{dirname}/include} for locally installed
+header files @emph{instead} of @file{/usr/local/include}.
+You should specify @option{--with-local-prefix} @strong{only} if your
+site has a different convention (not @file{/usr/local}) for where to put
+site-specific files.
+The default value for @option{--with-local-prefix} is @file{/usr/local}
+regardless of the value of @option{--prefix}.  Specifying
+@option{--prefix} has no effect on which directory GCC searches for
+local header files.  This may seem counterintuitive, but actually it is
+logical.
+The purpose of @option{--prefix} is to specify where to @emph{install
+GCC}.  The local header files in @file{/usr/local/include}---if you put
+any in that directory---are not part of GCC@.  They are part of other
+programs---perhaps many others.  (GCC installs its own header files in
+another directory which is based on the @option{--prefix} value.)
+Both the local-prefix include directory and the GCC-prefix include
+directory are part of GCC's ``system include'' directories.  Although these
+two directories are not fixed, they need to be searched in the proper
+order for the correct processing of the include_next directive.  The
+local-prefix include directory is searched before the GCC-prefix
+include directory.  Another characteristic of system include directories
+is that pedantic warnings are turned off for headers in these directories.
+Some autoconf macros add @option{-I @var{directory}} options to the
+compiler command line, to ensure that directories containing installed
+packages' headers are searched.  When @var{directory} is one of GCC's
+system include directories, GCC will ignore the option so that system
+directories continue to be processed in the correct order.  This
+may result in a search order different from what was specified but the
+directory will still be searched.
+GCC automatically searches for ordinary libraries using
+@env{GCC_EXEC_PREFIX}.  Thus, when the same installation prefix is
+used for both GCC and packages, GCC will automatically search for
+both headers and libraries.  This provides a configuration that is
+easy to use.  GCC behaves in a manner similar to that when it is
+installed as a system compiler in @file{/usr}.
+Sites that need to install multiple versions of GCC may not want to
+use the above simple configuration.  It is possible to use the
+@option{--program-prefix}, @option{--program-suffix} and
+@option{--program-transform-name} options to install multiple versions
+into a single directory, but it may be simpler to use different prefixes
+and the @option{--with-local-prefix} option to specify the location of the
+site-specific files for each version.  It will then be necessary for
+users to specify explicitly the location of local site libraries
+(e.g., with @env{LIBRARY_PATH}).
+The same value can be used for both @option{--with-local-prefix} and
+@option{--prefix} provided it is not @file{/usr}.  This can be used
+to avoid the default search of @file{/usr/local/include}.
+@strong{Do not} specify @file{/usr} as the @option{--with-local-prefix}!
+The directory you use for @option{--with-local-prefix} @strong{must not}
+contain any of the system's standard header files.  If it did contain
+them, certain programs would be miscompiled (including GNU Emacs, on
+certain targets), because this would override and nullify the header
+file corrections made by the @command{fixincludes} script.
+Indications are that people who use this option use it based on mistaken
+ideas of what it is for.  People use it as if it specified where to
+install part of GCC@.  Perhaps they make this assumption because
+installing GCC creates the directory.
+@item --enable-shared[=@var{package}[,@dots{}]]
+Build shared versions of libraries, if shared libraries are supported on
+the target platform.  Unlike GCC 2.95.x and earlier, shared libraries
+are enabled by default on all platforms that support shared libraries.
+If a list of packages is given as an argument, build shared libraries
+only for the listed packages.  For other packages, only static libraries
+will be built.  Package names currently recognized in the GCC tree are
+@samp{libgcc} (also known as @samp{gcc}), @samp{libstdc++} (not
+@samp{libstdc++-v3}), @samp{libffi}, @samp{zlib}, @samp{boehm-gc},
+@samp{ada}, @samp{libada}, @samp{libjava} and @samp{libobjc}.
+Note @samp{libiberty} does not support shared libraries at all.
+Use @option{--disable-shared} to build only static libraries.  Note that
+@option{--disable-shared} does not accept a list of package names as
+argument, only @option{--enable-shared} does.
+@item @anchor{with-gnu-as}--with-gnu-as
+Specify that the compiler should assume that the
+assembler it finds is the GNU assembler.  However, this does not modify
+the rules to find an assembler and will result in confusion if the
+assembler found is not actually the GNU assembler.  (Confusion may also
+result if the compiler finds the GNU assembler but has not been
+configured with @option{--with-gnu-as}.)  If you have more than one
+assembler installed on your system, you may want to use this option in
+connection with @option{--with-as=@var{pathname}} or
+@option{--with-build-time-tools=@var{pathname}}.
+The following systems are the only ones where it makes a difference
+whether you use the GNU assembler.  On any other system,
+@option{--with-gnu-as} has no effect.
+@itemize @bullet
+@item @samp{hppa1.0-@var{any}-@var{any}}
+@item @samp{hppa1.1-@var{any}-@var{any}}
+@item @samp{sparc-sun-solaris2.@var{any}}
+@item @samp{sparc64-@var{any}-solaris2.@var{any}}
+@end itemize
+@item @anchor{with-as}--with-as=@var{pathname}
+Specify that the compiler should use the assembler pointed to by
+@var{pathname}, rather than the one found by the standard rules to find
+an assembler, which are:
+@itemize @bullet
+@item
+Unless GCC is being built with a cross compiler, check the
+@file{@var{libexec}/gcc/@var{target}/@var{version}} directory.
+@var{libexec} defaults to @file{@var{exec-prefix}/libexec};
+@var{exec-prefix} defaults to @var{prefix}, which
+defaults to @file{/usr/local} unless overridden by the
+@option{--prefix=@var{pathname}} switch described above.  @var{target}
+is the target system triple, such as @samp{sparc-sun-solaris2.7}, and
+@var{version} denotes the GCC version, such as 3.0.
+@item
+If the target system is the same that you are building on, check
+operating system specific directories (e.g.@: @file{/usr/ccs/bin} on
+Sun Solaris 2).
+@item
+Check in the @env{PATH} for a tool whose name is prefixed by the
+target system triple.
+@item
+Check in the @env{PATH} for a tool whose name is not prefixed by the
+target system triple, if the host and target system triple are
+the same (in other words, we use a host tool if it can be used for
+the target as well).
+@end itemize
+You may want to use @option{--with-as} if no assembler
+is installed in the directories listed above, or if you have multiple
+assemblers installed and want to choose one that is not found by the
+above rules.
+@item @anchor{with-gnu-ld}--with-gnu-ld
+Same as @uref{#with-gnu-as,,@option{--with-gnu-as}}
+but for the linker.
+@item --with-ld=@var{pathname}
+Same as @uref{#with-as,,@option{--with-as}}
+but for the linker.
+@item --with-stabs
+Specify that stabs debugging
+information should be used instead of whatever format the host normally
+uses.  Normally GCC uses the same debug format as the host system.
+On MIPS based systems and on Alphas, you must specify whether you want
+GCC 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, GCC uses the ECOFF debugging format by default; if you
+prefer BSD stabs, specify @option{--with-stabs} when you configure GCC@.
+No matter which default you choose when you configure GCC, the user
+can use the @option{-gcoff} and @option{-gstabs+} options to specify explicitly
+the debug format for a particular compilation.
+@option{--with-stabs} is meaningful on the ISC system on the 386, also, if
+@option{--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.
+@option{--with-stabs} is also meaningful on 386 systems running SVR4.  It
+selects use of stabs debugging information embedded in ELF output.  The
+C++ compiler currently (2.6.0) does not support the DWARF debugging
+information normally used on 386 SVR4 platforms; stabs provide a
+workable alternative.  This requires gas and gdb, as the normal SVR4
+tools can not generate or interpret stabs.
+@item --disable-multilib
+Specify that multiple target
+libraries to support different target variants, calling
+conventions, etc.@: should not be built.  The default is to build a
+predefined set of them.
+Some targets provide finer-grained control over which multilibs are built
+(e.g., @option{--disable-softfloat}):
+@table @code
+@item arc-*-elf*
+biendian.
+@item arm-*-*
+fpu, 26bit, underscore, interwork, biendian, nofmult.
+@item m68*-*-*
+softfloat, m68881, m68000, m68020.
+@item mips*-*-*
+single-float, biendian, softfloat.
+@item powerpc*-*-*, rs6000*-*-*
+aix64, pthread, softfloat, powercpu, powerpccpu, powerpcos, biendian,
+sysv, aix.
+@end table
+@item --enable-threads
+Specify that the target
+supports threads.  This affects the Objective-C compiler and runtime
+library, and exception handling for other languages like C++ and Java.
+On some systems, this is the default.
+In general, the best (and, in many cases, the only known) threading
+model available will be configured for use.  Beware that on some
+systems, GCC has not been taught what threading models are generally
+available for the system.  In this case, @option{--enable-threads} is an
+alias for @option{--enable-threads=single}.
+@item --disable-threads
+Specify that threading support should be disabled for the system.
+This is an alias for @option{--enable-threads=single}.
+@item --enable-threads=@var{lib}
+Specify that
+@var{lib} is the thread support library.  This affects the Objective-C
+compiler and runtime library, and exception handling for other languages
+like C++ and Java.  The possibilities for @var{lib} are:
+@table @code
+@item aix
+AIX thread support.
+@item dce
+DCE thread support.
+@item gnat
+Ada tasking support.  For non-Ada programs, this setting is equivalent
+to @samp{single}.  When used in conjunction with the Ada run time, it
+causes GCC to use the same thread primitives as Ada uses.  This option
+is necessary when using both Ada and the back end exception handling,
+which is the default for most Ada targets.
+@item mach
+Generic MACH thread support, known to work on NeXTSTEP@.  (Please note
+that the file needed to support this configuration, @file{gthr-mach.h}, is
+missing and thus this setting will cause a known bootstrap failure.)
+@item no
+This is an alias for @samp{single}.
+@item posix
+Generic POSIX/Unix98 thread support.
+@item posix95
+Generic POSIX/Unix95 thread support.
+@item rtems
+RTEMS thread support.
+@item single
+Disable thread support, should work for all platforms.
+@item solaris
+Sun Solaris 2 thread support.
+@item vxworks
+VxWorks thread support.
+@item win32
+Microsoft Win32 API thread support.
+@item nks
+Novell Kernel Services thread support.
+@end table
+@item --enable-tls
+Specify that the target supports TLS (Thread Local Storage).  Usually
+configure can correctly determine if TLS is supported.  In cases where
+it guesses incorrectly, TLS can be explicitly enabled or disabled with
+@option{--enable-tls} or @option{--disable-tls}.  This can happen if
+the assembler supports TLS but the C library does not, or if the
+assumptions made by the configure test are incorrect.
+@item --disable-tls
+Specify that the target does not support TLS.
+This is an alias for @option{--enable-tls=no}.
+@item --with-cpu=@var{cpu}
+@itemx --with-cpu-32=@var{cpu}
+@itemx --with-cpu-64=@var{cpu}
+Specify which cpu variant the compiler should generate code for by default.
+@var{cpu} will be used as the default value of the @option{-mcpu=} switch.
+This option is only supported on some targets, including ARM, i386, M68k,
+PowerPC, and SPARC@.  The @option{--with-cpu-32} and
+@option{--with-cpu-64} options specify separate default CPUs for
+32-bit and 64-bit modes; these options are only supported for i386 and
+x86-64.
+@item --with-schedule=@var{cpu}
+@itemx --with-arch=@var{cpu}
+@itemx --with-arch-32=@var{cpu}
+@itemx --with-arch-64=@var{cpu}
+@itemx --with-tune=@var{cpu}
+@itemx --with-tune-32=@var{cpu}
+@itemx --with-tune-64=@var{cpu}
+@itemx --with-abi=@var{abi}
+@itemx --with-fpu=@var{type}
+@itemx --with-float=@var{type}
+These configure options provide default values for the @option{-mschedule=},
+@option{-march=}, @option{-mtune=}, @option{-mabi=}, and @option{-mfpu=}
+options and for @option{-mhard-float} or @option{-msoft-float}.  As with
+@option{--with-cpu}, which switches will be accepted and acceptable values
+of the arguments depend on the target.
+@item --with-mode=@var{mode}
+Specify if the compiler should default to @option{-marm} or @option{-mthumb}.
+This option is only supported on ARM targets.
+@item --with-divide=@var{type}
+Specify how the compiler should generate code for checking for
+division by zero.  This option is only supported on the MIPS target.
+The possibilities for @var{type} are:
+@table @code
+@item traps
+Division by zero checks use conditional traps (this is the default on
+systems that support conditional traps).
+@item breaks
+Division by zero checks use the break instruction.
+@end table
+@c If you make --with-llsc the default for additional targets,
+@c update the --with-llsc description in the MIPS section below.
+@item --with-llsc
+On MIPS targets, make @option{-mllsc} the default when no
+@option{-mno-lsc} option is passed.  This is the default for
+Linux-based targets, as the kernel will emulate them if the ISA does
+not provide them.
+@item --without-llsc
+On MIPS targets, make @option{-mno-llsc} the default when no
+@option{-mllsc} option is passed.
+@item --with-mips-plt
+On MIPS targets, make use of copy relocations and PLTs.
+These features are extensions to the traditional
+SVR4-based MIPS ABIs and require support from GNU binutils
+and the runtime C library.
+@item --enable-__cxa_atexit
+Define if you want to use __cxa_atexit, rather than atexit, to
+register C++ destructors for local statics and global objects.
+This is essential for fully standards-compliant handling of
+destructors, but requires __cxa_atexit in libc.  This option is currently
+only available on systems with GNU libc.  When enabled, this will cause
+@option{-fuse-cxa-atexit} to be passed by default.
+@item --enable-target-optspace
+Specify that target
+libraries should be optimized for code space instead of code speed.
+This is the default for the m32r platform.
+@item --disable-cpp
+Specify that a user visible @command{cpp} program should not be installed.
+@item --with-cpp-install-dir=@var{dirname}
+Specify that the user visible @command{cpp} program should be installed
+in @file{@var{prefix}/@var{dirname}/cpp}, in addition to @var{bindir}.
+@item --enable-initfini-array
+Force the use of sections @code{.init_array} and @code{.fini_array}
+(instead of @code{.init} and @code{.fini}) for constructors and
+destructors.  Option @option{--disable-initfini-array} has the
+opposite effect.  If neither option is specified, the configure script
+will try to guess whether the @code{.init_array} and
+@code{.fini_array} sections are supported and, if they are, use them.
+@item --enable-maintainer-mode
+The build rules that
+regenerate the GCC master message catalog @file{gcc.pot} are normally
+disabled.  This is because it can only be rebuilt if the complete source
+tree is present.  If you have changed the sources and want to rebuild the
+catalog, configuring with @option{--enable-maintainer-mode} will enable
+this.  Note that you need a recent version of the @code{gettext} tools
+to do so.
+@item --disable-bootstrap
+For a native build, the default configuration is to perform
+a 3-stage bootstrap of the compiler when @samp{make} is invoked,
+testing that GCC can compile itself correctly.  If you want to disable
+this process, you can configure with @option{--disable-bootstrap}.
+@item --enable-bootstrap
+In special cases, you may want to perform a 3-stage build
+even if the target and host triplets are different.
+This could happen when the host can run code compiled for
+the target (e.g.@: host is i686-linux, target is i486-linux).
+Starting from GCC 4.2, to do this you have to configure explicitly
+with @option{--enable-bootstrap}.
+@item --enable-generated-files-in-srcdir
+Neither the .c and .h files that are generated from Bison and flex nor the
+info manuals and man pages that are built from the .texi files are present
+in the SVN development tree.  When building GCC from that development tree,
+or from one of our snapshots, those generated files are placed in your
+build directory, which allows for the source to be in a readonly
+directory.
+If you configure with @option{--enable-generated-files-in-srcdir} then those
+generated files will go into the source directory.  This is mainly intended
+for generating release or prerelease tarballs of the GCC sources, since it
+is not a requirement that the users of source releases to have flex, Bison,
+or makeinfo.
+@item --enable-version-specific-runtime-libs
+Specify
+that runtime libraries should be installed in the compiler specific
+subdirectory (@file{@var{libdir}/gcc}) rather than the usual places.  In
+addition, @samp{libstdc++}'s include files will be installed into
+@file{@var{libdir}} unless you overruled it by using
+@option{--with-gxx-include-dir=@var{dirname}}.  Using this option is
+particularly useful if you intend to use several versions of GCC in
+parallel.  This is currently supported by @samp{libgfortran},
+@samp{libjava}, @samp{libmudflap}, @samp{libstdc++}, and @samp{libobjc}.
+@item --enable-languages=@var{lang1},@var{lang2},@dots{}
+Specify that only a particular subset of compilers and
+their runtime libraries should be built.  For a list of valid values for
+@var{langN} you can issue the following command in the
+@file{gcc} directory of your GCC source tree:@*
+@smallexample
+grep language= */config-lang.in
+@end smallexample
+Currently, you can use any of the following:
+@code{all}, @code{ada}, @code{c}, @code{c++}, @code{fortran}, @code{java},
+@code{objc}, @code{obj-c++}.
+Building the Ada compiler has special requirements, see below.
+If you do not pass this flag, or specify the option @code{all}, then all
+default languages available in the @file{gcc} sub-tree will be configured.
+Ada and Objective-C++ are not default languages; the rest are.
+Re-defining @code{LANGUAGES} when calling @samp{make} @strong{does not}
+work anymore, as those language sub-directories might not have been
+configured!
+@item --enable-stage1-languages=@var{lang1},@var{lang2},@dots{}
+Specify that a particular subset of compilers and their runtime
+libraries should be built with the system C compiler during stage 1 of
+the bootstrap process, rather than only in later stages with the
+bootstrapped C compiler.  The list of valid values is the same as for
+@option{--enable-languages}, and the option @code{all} will select all
+of the languages enabled by @option{--enable-languages}.  This option is
+primarily useful for GCC development; for instance, when a development
+version of the compiler cannot bootstrap due to compiler bugs, or when
+one is debugging front ends other than the C front end.  When this
+option is used, one can then build the target libraries for the
+specified languages with the stage-1 compiler by using @command{make
+stage1-bubble all-target}, or run the testsuite on the stage-1 compiler
+for the specified languages using @command{make stage1-start check-gcc}.
+@item --disable-libada
+Specify that the run-time libraries and tools used by GNAT should not
+be built.  This can be useful for debugging, or for compatibility with
+previous Ada build procedures, when it was required to explicitly
+do a @samp{make -C gcc gnatlib_and_tools}.
+@item --disable-libssp
+Specify that the run-time libraries for stack smashing protection
+should not be built.
+@item --disable-libgomp
+Specify that the run-time libraries used by GOMP should not be built.
+@item --with-dwarf2
+Specify that the compiler should
+use DWARF 2 debugging information as the default.
+@item --enable-targets=all
+@itemx --enable-targets=@var{target_list}
+Some GCC targets, e.g.@: powerpc64-linux, build bi-arch compilers.
+These are compilers that are able to generate either 64-bit or 32-bit
+code.  Typically, the corresponding 32-bit target, e.g.@:
+powerpc-linux for powerpc64-linux, only generates 32-bit code.  This
+option enables the 32-bit target to be a bi-arch compiler, which is
+useful when you want a bi-arch compiler that defaults to 32-bit, and
+you are building a bi-arch or multi-arch binutils in a combined tree.
+Currently, this option only affects sparc-linux, powerpc-linux and
+x86-linux.
+@item --enable-secureplt
+This option enables @option{-msecure-plt} by default for powerpc-linux.
+@ifnothtml
+@xref{RS/6000 and PowerPC Options,, RS/6000 and PowerPC Options, gcc,
+Using the GNU Compiler Collection (GCC)},
+@end ifnothtml
+@ifhtml
+See ``RS/6000 and PowerPC Options'' in the main manual
+@end ifhtml
+@item --enable-cld
+This option enables @option{-mcld} by default for 32-bit x86 targets.
+@ifnothtml
+@xref{i386 and x86-64 Options,, i386 and x86-64 Options, gcc,
+Using the GNU Compiler Collection (GCC)},
+@end ifnothtml
+@ifhtml
+See ``i386 and x86-64 Options'' in the main manual
+@end ifhtml
+@item --enable-win32-registry
+@itemx --enable-win32-registry=@var{key}
+@itemx --disable-win32-registry
+The @option{--enable-win32-registry} option enables Microsoft Windows-hosted GCC
+to look up installations paths in the registry using the following key:
+@smallexample
+@code{HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\@var{key}}
+@end smallexample
+@var{key} defaults to GCC version number, and can be overridden by the
+@option{--enable-win32-registry=@var{key}} option.  Vendors and distributors
+who use custom installers are encouraged to provide a different key,
+perhaps one comprised of vendor name and GCC version number, to
+avoid conflict with existing installations.  This feature is enabled
+by default, and can be disabled by @option{--disable-win32-registry}
+option.  This option has no effect on the other hosts.
+@item --nfp
+Specify that the machine does not have a floating point unit.  This
+option only applies to @samp{m68k-sun-sunos@var{n}}.  On any other
+system, @option{--nfp} has no effect.
+@item --enable-werror
+@itemx --disable-werror
+@itemx --enable-werror=yes
+@itemx --enable-werror=no
+When you specify this option, it controls whether certain files in the
+compiler are built with @option{-Werror} in bootstrap stage2 and later.
+If you don't specify it, @option{-Werror} is turned on for the main
+development trunk.  However it defaults to off for release branches and
+final releases.  The specific files which get @option{-Werror} are
+controlled by the Makefiles.
+@item --enable-checking
+@itemx --enable-checking=@var{list}
+When you specify this option, the compiler is built to perform internal
+consistency checks of the requested complexity.  This does not change the
+generated code, but adds error checking within the compiler.  This will
+slow down the compiler and may only work properly if you are building
+the compiler with GCC@.  This is @samp{yes} by default when building
+from SVN or snapshots, but @samp{release} for releases.  The default
+for building the stage1 compiler is @samp{yes}.  More control
+over the checks may be had by specifying @var{list}.  The categories of
+checks available are @samp{yes} (most common checks
+@samp{assert,misc,tree,gc,rtlflag,runtime}), @samp{no} (no checks at
+all), @samp{all} (all but @samp{valgrind}), @samp{release} (cheapest
+checks @samp{assert,runtime}) or @samp{none} (same as @samp{no}).
+Individual checks can be enabled with these flags @samp{assert},
+@samp{df}, @samp{fold}, @samp{gc}, @samp{gcac} @samp{misc}, @samp{rtl},
+@samp{rtlflag}, @samp{runtime}, @samp{tree}, and @samp{valgrind}.
+The @samp{valgrind} check requires the external @command{valgrind}
+simulator, available from @uref{http://valgrind.org/}.  The
+@samp{df}, @samp{rtl}, @samp{gcac} and @samp{valgrind} checks are very expensive.
+To disable all checking, @samp{--disable-checking} or
+@samp{--enable-checking=none} must be explicitly requested.  Disabling
+assertions will make the compiler and runtime slightly faster but
+increase the risk of undetected internal errors causing wrong code to be
+generated.
+@item --disable-stage1-checking
+@item --enable-stage1-checking
+@itemx --enable-stage1-checking=@var{list}
+If no @option{--enable-checking} option is specified the stage1
+compiler will be built with @samp{yes} checking enabled, otherwise
+the stage1 checking flags are the same as specified by
+@option{--enable-checking}.  To build the stage1 compiler with
+different checking options use @option{--enable-stage1-checking}.
+The list of checking options is the same as for @option{--enable-checking}.
+If your system is too slow or too small to bootstrap a released compiler
+with checking for stage1 enabled, you can use @samp{--disable-stage1-checking}
+to disable checking for the stage1 compiler.
+@item --enable-coverage
+@itemx --enable-coverage=@var{level}
+With this option, the compiler is built to collect self coverage
+information, every time it is run.  This is for internal development
+purposes, and only works when the compiler is being built with gcc.  The
+@var{level} argument controls whether the compiler is built optimized or
+not, values are @samp{opt} and @samp{noopt}.  For coverage analysis you
+want to disable optimization, for performance analysis you want to
+enable optimization.  When coverage is enabled, the default level is
+without optimization.
+@item --enable-gather-detailed-mem-stats
+When this option is specified more detailed information on memory
+allocation is gathered.  This information is printed when using
+@option{-fmem-report}.
+@item --with-gc
+@itemx --with-gc=@var{choice}
+With this option you can specify the garbage collector implementation
+used during the compilation process.  @var{choice} can be one of
+@samp{page} and @samp{zone}, where @samp{page} is the default.
+@item --enable-nls
+@itemx --disable-nls
+The @option{--enable-nls} option enables Native Language Support (NLS),
+which lets GCC output diagnostics in languages other than American
+English.  Native Language Support is enabled by default if not doing a
+canadian cross build.  The @option{--disable-nls} option disables NLS@.
+@item --with-included-gettext
+If NLS is enabled, the @option{--with-included-gettext} option causes the build
+procedure to prefer its copy of GNU @command{gettext}.
+@item --with-catgets
+If NLS is enabled, and if the host lacks @code{gettext} but has the
+inferior @code{catgets} interface, the GCC build procedure normally
+ignores @code{catgets} and instead uses GCC's copy of the GNU
+@code{gettext} library.  The @option{--with-catgets} option causes the
+build procedure to use the host's @code{catgets} in this situation.
+@item --with-libiconv-prefix=@var{dir}
+Search for libiconv header files in @file{@var{dir}/include} and
+libiconv library files in @file{@var{dir}/lib}.
+@item --enable-obsolete
+Enable configuration for an obsoleted system.  If you attempt to
+configure GCC for a system (build, host, or target) which has been
+obsoleted, and you do not specify this flag, configure will halt with an
+error message.
+All support for systems which have been obsoleted in one release of GCC
+is removed entirely in the next major release, unless someone steps
+forward to maintain the port.
+@item --enable-decimal-float
+@itemx --enable-decimal-float=yes
+@itemx --enable-decimal-float=no
+@itemx --enable-decimal-float=bid
+@itemx --enable-decimal-float=dpd
+@itemx --disable-decimal-float
+Enable (or disable) support for the C decimal floating point extension
+that is in the IEEE 754-2008 standard.  This is enabled by default only
+on PowerPC, i386, and x86_64 GNU/Linux systems.  Other systems may also
+support it, but require the user to specifically enable it.  You can
+optionally control which decimal floating point format is used (either
+@samp{bid} or @samp{dpd}).  The @samp{bid} (binary integer decimal)
+format is default on i386 and x86_64 systems, and the @samp{dpd}
+(densely packed decimal) format is default on PowerPC systems.
+@item --enable-fixed-point
+@itemx --disable-fixed-point
+Enable (or disable) support for C fixed-point arithmetic.
+This option is enabled by default for some targets (such as MIPS) which
+have hardware-support for fixed-point operations.  On other targets, you
+may enable this option manually.
+@item --with-long-double-128
+Specify if @code{long double} type should be 128-bit by default on selected
+GNU/Linux architectures.  If using @code{--without-long-double-128},
+@code{long double} will be by default 64-bit, the same as @code{double} type.
+When neither of these configure options are used, the default will be
+128-bit @code{long double} when built against GNU C Library 2.4 and later,
+64-bit @code{long double} otherwise.
+@item --with-gmp=@var{pathname}
+@itemx --with-gmp-include=@var{pathname}
+@itemx --with-gmp-lib=@var{pathname}
+@itemx --with-mpfr=@var{pathname}
+@itemx --with-mpfr-include=@var{pathname}
+@itemx --with-mpfr-lib=@var{pathname}
+If you do not have GMP (the GNU Multiple Precision library) and the
+MPFR Libraries installed in a standard location and you want to build
+GCC, you can explicitly specify the directory where they are installed
+(@samp{--with-gmp=@var{gmpinstalldir}},
+@samp{--with-mpfr=@var{mpfrinstalldir}}).  The
+@option{--with-gmp=@var{gmpinstalldir}} option is shorthand for
+@option{--with-gmp-lib=@var{gmpinstalldir}/lib} and
+@option{--with-gmp-include=@var{gmpinstalldir}/include}.  Likewise the
+@option{--with-mpfr=@var{mpfrinstalldir}} option is shorthand for
+@option{--with-mpfr-lib=@var{mpfrinstalldir}/lib} and
+@option{--with-mpfr-include=@var{mpfrinstalldir}/include}.  If these
+shorthand assumptions are not correct, you can use the explicit
+include and lib options directly.
+@item --with-ppl=@var{pathname}
+@itemx --with-ppl-include=@var{pathname}
+@itemx --with-ppl-lib=@var{pathname}
+@itemx --with-cloog=@var{pathname}
+@itemx --with-cloog-include=@var{pathname}
+@itemx --with-cloog-lib=@var{pathname}
+If you do not have PPL (the Parma Polyhedra Library) and the CLooG
+libraries installed in a standard location and you want to build GCC,
+you can explicitly specify the directory where they are installed
+(@samp{--with-ppl=@var{pplinstalldir}},
+@samp{--with-cloog=@var{clooginstalldir}}). The
+@option{--with-ppl=@var{pplinstalldir}} option is shorthand for
+@option{--with-ppl-lib=@var{pplinstalldir}/lib} and
+@option{--with-ppl-include=@var{pplinstalldir}/include}.  Likewise the
+@option{--with-cloog=@var{clooginstalldir}} option is shorthand for
+@option{--with-cloog-lib=@var{clooginstalldir}/lib} and
+@option{--with-cloog-include=@var{clooginstalldir}/include}.  If these
+shorthand assumptions are not correct, you can use the explicit
+include and lib options directly.
+@item --with-host-libstdcxx=@var{linker-args}
+If you are linking with a static copy of PPL, you can use this option
+to specify how the linker should find the standard C++ library used
+internally by PPL.  Typical values of @var{linker-args} might be
+@samp{-lstdc++} or @samp{-Wl,-Bstatic,-lstdc++,-Bdynamic -lm}.  If you are
+linking with a shared copy of PPL, you probably do not need this
+option; shared library dependencies will cause the linker to search
+for the standard C++ library automatically.
+@item --with-debug-prefix-map=@var{map}
+Convert source directory names using @option{-fdebug-prefix-map} when
+building runtime libraries.  @samp{@var{map}} is a space-separated
+list of maps of the form @samp{@var{old}=@var{new}}.
+@end table
+@subheading Cross-Compiler-Specific Options
+The following options only apply to building cross compilers.
+@table @code
+@item --with-sysroot
+@itemx --with-sysroot=@var{dir}
+Tells GCC to consider @var{dir} as the root of a tree that contains a
+(subset of) the root filesystem of the target operating system.
+Target system headers, libraries and run-time object files will be
+searched in there.  The specified directory is not copied into the
+install tree, unlike the options @option{--with-headers} and
+@option{--with-libs} that this option obsoletes.  The default value,
+in case @option{--with-sysroot} is not given an argument, is
+@option{$@{gcc_tooldir@}/sys-root}.  If the specified directory is a
+subdirectory of @option{$@{exec_prefix@}}, then it will be found relative to
+the GCC binaries if the installation tree is moved.
+@item --with-build-sysroot
+@itemx --with-build-sysroot=@var{dir}
+Tells GCC to consider @var{dir} as the system root (see
+@option{--with-sysroot}) while building target libraries, instead of
+the directory specified with @option{--with-sysroot}.  This option is
+only useful when you are already using @option{--with-sysroot}.  You
+can use @option{--with-build-sysroot} when you are configuring with
+@option{--prefix} set to a directory that is different from the one in
+which you are installing GCC and your target libraries.
+This option affects the system root for the compiler used to build
+target libraries (which runs on the build system); it does not affect
+the compiler which is used to build GCC itself.
+@item --with-headers
+@itemx --with-headers=@var{dir}
+Deprecated in favor of @option{--with-sysroot}.
+Specifies that target headers are available when building a cross compiler.
+The @var{dir} argument specifies a directory which has the target include
+files.  These include files will be copied into the @file{gcc} install
+directory.  @emph{This option with the @var{dir} argument is required} when
+building a cross compiler, if @file{@var{prefix}/@var{target}/sys-include}
+doesn't pre-exist.  If @file{@var{prefix}/@var{target}/sys-include} does
+pre-exist, the @var{dir} argument may be omitted.  @command{fixincludes}
+will be run on these files to make them compatible with GCC@.
+@item --without-headers
+Tells GCC not use any target headers from a libc when building a cross
+compiler.  When crossing to GNU/Linux, you need the headers so GCC
+can build the exception handling for libgcc.
+@item --with-libs
+@itemx --with-libs=``@var{dir1} @var{dir2} @dots{} @var{dirN}''
+Deprecated in favor of @option{--with-sysroot}.
+Specifies a list of directories which contain the target runtime
+libraries.  These libraries will be copied into the @file{gcc} install
+directory.  If the directory list is omitted, this option has no
+effect.
+@item --with-newlib
+Specifies that @samp{newlib} is
+being used as the target C library.  This causes @code{__eprintf} to be
+omitted from @file{libgcc.a} on the assumption that it will be provided by
+@samp{newlib}.
+@item --with-build-time-tools=@var{dir}
+Specifies where to find the set of target tools (assembler, linker, etc.)
+that will be used while building GCC itself.  This option can be useful
+if the directory layouts are different between the system you are building
+GCC on, and the system where you will deploy it.
+For example, on a @option{ia64-hp-hpux} system, you may have the GNU
+assembler and linker in @file{/usr/bin}, and the native tools in a
+different path, and build a toolchain that expects to find the
+native tools in @file{/usr/bin}.
+When you use this option, you should ensure that @var{dir} includes
+@command{ar}, @command{as}, @command{ld}, @command{nm},
+@command{ranlib} and @command{strip} if necessary, and possibly
+@command{objdump}.  Otherwise, GCC may use an inconsistent set of
+tools.
+@end table
+@subheading Java-Specific Options
+The following option applies to the build of the Java front end.
+@table @code
+@item --disable-libgcj
+Specify that the run-time libraries
+used by GCJ should not be built.  This is useful in case you intend
+to use GCJ with some other run-time, or you're going to install it
+separately, or it just happens not to build on your particular
+machine.  In general, if the Java front end is enabled, the GCJ
+libraries will be enabled too, unless they're known to not work on
+the target platform.  If GCJ is enabled but @samp{libgcj} isn't built, you
+may need to port it; in this case, before modifying the top-level
+@file{configure.in} so that @samp{libgcj} is enabled by default on this platform,
+you may use @option{--enable-libgcj} to override the default.
+@end table
+The following options apply to building @samp{libgcj}.
+@subsubheading General Options
+@table @code
+@item --enable-java-maintainer-mode
+By default the @samp{libjava} build will not attempt to compile the
+@file{.java} source files to @file{.class}.  Instead, it will use the
+@file{.class} files from the source tree.  If you use this option you
+must have executables named @command{ecj1} and @command{gjavah} in your path
+for use by the build.  You must use this option if you intend to
+modify any @file{.java} files in @file{libjava}.
+@item --with-java-home=@var{dirname}
+This @samp{libjava} option overrides the default value of the
+@samp{java.home} system property.  It is also used to set
+@samp{sun.boot.class.path} to @file{@var{dirname}/lib/rt.jar}.  By
+default @samp{java.home} is set to @file{@var{prefix}} and
+@samp{sun.boot.class.path} to
+@file{@var{datadir}/java/libgcj-@var{version}.jar}.
+@item --with-ecj-jar=@var{filename}
+This option can be used to specify the location of an external jar
+file containing the Eclipse Java compiler.  A specially modified
+version of this compiler is used by @command{gcj} to parse
+@file{.java} source files.  If this option is given, the
+@samp{libjava} build will create and install an @file{ecj1} executable
+which uses this jar file at runtime.
+If this option is not given, but an @file{ecj.jar} file is found in
+the topmost source tree at configure time, then the @samp{libgcj}
+build will create and install @file{ecj1}, and will also install the
+discovered @file{ecj.jar} into a suitable place in the install tree.
+If @file{ecj1} is not installed, then the user will have to supply one
+on his path in order for @command{gcj} to properly parse @file{.java}
+source files.  A suitable jar is available from
+@uref{ftp://sourceware.org/pub/java/}.
+@item --disable-getenv-properties
+Don't set system properties from @env{GCJ_PROPERTIES}.
+@item --enable-hash-synchronization
+Use a global hash table for monitor locks.  Ordinarily,
+@samp{libgcj}'s @samp{configure} script automatically makes
+the correct choice for this option for your platform.  Only use
+this if you know you need the library to be configured differently.
+@item --enable-interpreter
+Enable the Java interpreter.  The interpreter is automatically
+enabled by default on all platforms that support it.  This option
+is really only useful if you want to disable the interpreter
+(using @option{--disable-interpreter}).
+@item --disable-java-net
+Disable java.net.  This disables the native part of java.net only,
+using non-functional stubs for native method implementations.
+@item --disable-jvmpi
+Disable JVMPI support.
+@item --disable-libgcj-bc
+Disable BC ABI compilation of certain parts of libgcj.  By default,
+some portions of libgcj are compiled with @option{-findirect-dispatch}
+and @option{-fno-indirect-classes}, allowing them to be overridden at
+run-time.
+If @option{--disable-libgcj-bc} is specified, libgcj is built without
+these options.  This allows the compile-time linker to resolve
+dependencies when statically linking to libgcj.  However it makes it
+impossible to override the affected portions of libgcj at run-time.
+@item --enable-reduced-reflection
+Build most of libgcj with @option{-freduced-reflection}.  This reduces
+the size of libgcj at the expense of not being able to do accurate
+reflection on the classes it contains.  This option is safe if you
+know that code using libgcj will never use reflection on the standard
+runtime classes in libgcj (including using serialization, RMI or CORBA).
+@item --with-ecos
+Enable runtime eCos target support.
+@item --without-libffi
+Don't use @samp{libffi}.  This will disable the interpreter and JNI
+support as well, as these require @samp{libffi} to work.
+@item --enable-libgcj-debug
+Enable runtime debugging code.
+@item --enable-libgcj-multifile
+If specified, causes all @file{.java} source files to be
+compiled into @file{.class} files in one invocation of
+@samp{gcj}.  This can speed up build time, but is more
+resource-intensive.  If this option is unspecified or
+disabled, @samp{gcj} is invoked once for each @file{.java}
+file to compile into a @file{.class} file.
+@item --with-libiconv-prefix=DIR
+Search for libiconv in @file{DIR/include} and @file{DIR/lib}.
+@item --enable-sjlj-exceptions
+Force use of the @code{setjmp}/@code{longjmp}-based scheme for exceptions.
+@samp{configure} ordinarily picks the correct value based on the platform.
+Only use this option if you are sure you need a different setting.
+@item --with-system-zlib
+Use installed @samp{zlib} rather than that included with GCC@.
+@item --with-win32-nlsapi=ansi, unicows or unicode
+Indicates how MinGW @samp{libgcj} translates between UNICODE
+characters and the Win32 API@.
+@item --enable-java-home
+If enabled, this creates a JPackage compatible SDK environment during install.
+Note that if --enable-java-home is used, --with-arch-directory=ARCH must also
+be specified.
+@item --with-arch-directory=ARCH
+Specifies the name to use for the @file{jre/lib/ARCH} directory in the SDK
+environment created when --enable-java-home is passed. Typical names for this
+directory include i386, amd64, ia64, etc.
+@item --with-os-directory=DIR
+Specifies the OS directory for the SDK include directory. This is set to auto
+detect, and is typically 'linux'.
+@item --with-origin-name=NAME
+Specifies the JPackage origin name. This defaults to the 'gcj' in
+java-1.5.0-gcj.
+@item --with-arch-suffix=SUFFIX
+Specifies the suffix for the sdk directory. Defaults to the empty string.
+Examples include '.x86_64' in 'java-1.5.0-gcj-1.5.0.0.x86_64'.
+@item --with-jvm-root-dir=DIR
+Specifies where to install the SDK. Default is $(prefix)/lib/jvm.
+@item --with-jvm-jar-dir=DIR
+Specifies where to install jars. Default is $(prefix)/lib/jvm-exports.
+@item --with-python-dir=DIR
+Specifies where to install the Python modules used for aot-compile. DIR should
+not include the prefix used in installation. For example, if the Python modules
+are to be installed in /usr/lib/python2.5/site-packages, then
+--with-python-dir=/lib/python2.5/site-packages should be passed. If this is
+not specified, then the Python modules are installed in $(prefix)/share/python.
+@item --enable-aot-compile-rpm
+Adds aot-compile-rpm to the list of installed scripts.
+@table @code
+@item ansi
+Use the single-byte @code{char} and the Win32 A functions natively,
+translating to and from UNICODE when using these functions.  If
+unspecified, this is the default.
+@item unicows
+Use the @code{WCHAR} and Win32 W functions natively.  Adds
+@code{-lunicows} to @file{libgcj.spec} to link with @samp{libunicows}.
+@file{unicows.dll} needs to be deployed on Microsoft Windows 9X machines
+running built executables.  @file{libunicows.a}, an open-source
+import library around Microsoft's @code{unicows.dll}, is obtained from
+@uref{http://libunicows.sourceforge.net/}, which also gives details
+on getting @file{unicows.dll} from Microsoft.
+@item unicode
+Use the @code{WCHAR} and Win32 W functions natively.  Does @emph{not}
+add @code{-lunicows} to @file{libgcj.spec}.  The built executables will
+only run on Microsoft Windows NT and above.
+@end table
+@end table
+@subsubheading AWT-Specific Options
+@table @code
+@item --with-x
+Use the X Window System.
+@item --enable-java-awt=PEER(S)
+Specifies the AWT peer library or libraries to build alongside
+@samp{libgcj}.  If this option is unspecified or disabled, AWT
+will be non-functional.  Current valid values are @option{gtk} and
+@option{xlib}.  Multiple libraries should be separated by a
+comma (i.e.@: @option{--enable-java-awt=gtk,xlib}).
+@item --enable-gtk-cairo
+Build the cairo Graphics2D implementation on GTK@.
+@item --enable-java-gc=TYPE
+Choose garbage collector.  Defaults to @option{boehm} if unspecified.
+@item --disable-gtktest
+Do not try to compile and run a test GTK+ program.
+@item --disable-glibtest
+Do not try to compile and run a test GLIB program.
+@item --with-libart-prefix=PFX
+Prefix where libart is installed (optional).
+@item --with-libart-exec-prefix=PFX
+Exec prefix where libart is installed (optional).
+@item --disable-libarttest
+Do not try to compile and run a test libart program.
+@end table
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+@c ***Building****************************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Building, Testing, Configuration, Installing GCC
+@end ifnothtml
+@ifset buildhtml
+@ifnothtml
+@chapter Building
+@end ifnothtml
+@cindex Installing GCC: Building
+Now that GCC is configured, you are ready to build the compiler and
+runtime libraries.
+Some commands executed when making the compiler may fail (return a
+nonzero status) and be ignored by @command{make}.  These failures, which
+are often due to files that were not found, are expected, and can safely
+be ignored.
+It is normal to have compiler warnings when compiling certain files.
+Unless you are a GCC developer, you can generally ignore these warnings
+unless they cause compilation to fail.  Developers should attempt to fix
+any warnings encountered, however they can temporarily continue past
+warnings-as-errors by specifying the configure flag
+@option{--disable-werror}.
+On certain old systems, defining certain environment variables such as
+@env{CC} can interfere with the functioning of @command{make}.
+If you encounter seemingly strange errors when trying to build the
+compiler in a directory other than the source directory, it could be
+because you have previously configured the compiler in the source
+directory.  Make sure you have done all the necessary preparations.
+If you build GCC on a BSD system using a directory stored in an old System
+V file system, problems may occur in running @command{fixincludes} if the
+System V file system doesn't support symbolic links.  These problems
+result in a failure to fix the declaration of @code{size_t} in
+@file{sys/types.h}.  If you find that @code{size_t} is a signed type and
+that type mismatches occur, this could be the cause.
+The solution is not to use such a directory for building GCC@.
+Similarly, when building from SVN or snapshots, or if you modify
+@file{*.l} files, you need the Flex lexical analyzer generator
+installed.  If you do not modify @file{*.l} files, releases contain
+the Flex-generated files and you do not need Flex installed to build
+them.  There is still one Flex-based lexical analyzer (part of the
+build machinery, not of GCC itself) that is used even if you only
+build the C front end.
+When building from SVN or snapshots, or if you modify Texinfo
+documentation, you need version 4.7 or later of Texinfo installed if you
+want Info documentation to be regenerated.  Releases contain Info
+documentation pre-built for the unmodified documentation in the release.
+@section Building a native compiler
+For a native build, the default configuration is to perform
+a 3-stage bootstrap of the compiler when @samp{make} is invoked.
+This will build the entire GCC system and ensure that it compiles
+itself correctly.  It can be disabled with the @option{--disable-bootstrap}
+parameter to @samp{configure}, but bootstrapping is suggested because
+the compiler will be tested more completely and could also have
+better performance.
+The bootstrapping process will complete the following steps:
+@itemize @bullet
+@item
+Build tools necessary to build the compiler.
+@item
+Perform a 3-stage bootstrap of the compiler.  This includes building
+three times the target tools for use by the compiler such as binutils
+(bfd, binutils, gas, gprof, ld, and opcodes) if they have been
+individually linked or moved into the top level GCC source tree before
+configuring.
+@item
+Perform a comparison test of the stage2 and stage3 compilers.
+@item
+Build runtime libraries using the stage3 compiler from the previous step.
+@end itemize
+If you are short on disk space you might consider @samp{make
+bootstrap-lean} instead.  The sequence of compilation is the
+same described above, but object files from the stage1 and
+stage2 of the 3-stage bootstrap of the compiler are deleted as
+soon as they are no longer needed.
+If you wish to use non-default GCC flags when compiling the stage2
+and stage3 compilers, set @code{BOOT_CFLAGS} on the command line when
+doing @samp{make}.  For example, if you want to save additional space
+during the bootstrap and in the final installation as well, you can
+build the compiler binaries without debugging information as in the
+following example.  This will save roughly 40% of disk space both for
+the bootstrap and the final installation.  (Libraries will still contain
+debugging information.)
+@smallexample
+make BOOT_CFLAGS='-O' bootstrap
+@end smallexample
+You can place non-default optimization flags into @code{BOOT_CFLAGS}; they
+are less well tested here than the default of @samp{-g -O2}, but should
+still work.  In a few cases, you may find that you need to specify special
+flags such as @option{-msoft-float} here to complete the bootstrap; or,
+if the native compiler miscompiles the stage1 compiler, you may need
+to work around this, by choosing @code{BOOT_CFLAGS} to avoid the parts
+of the stage1 compiler that were miscompiled, or by using @samp{make
+bootstrap4} to increase the number of stages of bootstrap.
+@code{BOOT_CFLAGS} does not apply to bootstrapped target libraries.
+Since these are always compiled with the compiler currently being
+bootstrapped, you can use @code{CFLAGS_FOR_TARGET} to modify their
+compilation flags, as for non-bootstrapped target libraries.
+Again, if the native compiler miscompiles the stage1 compiler, you may
+need to work around this by avoiding non-working parts of the stage1
+compiler.  Use @code{STAGE1_LIBCFLAGS} to this end.
+If you used the flag @option{--enable-languages=@dots{}} to restrict
+the compilers to be built, only those you've actually enabled will be
+built.  This will of course only build those runtime libraries, for
+which the particular compiler has been built.  Please note,
+that re-defining @env{LANGUAGES} when calling @samp{make}
+@strong{does not} work anymore!
+If the comparison of stage2 and stage3 fails, this normally indicates
+that the stage2 compiler has compiled GCC incorrectly, and is therefore
+a potentially serious bug which you should investigate and report.  (On
+a few systems, meaningful comparison of object files is impossible; they
+always appear ``different''.  If you encounter this problem, you will
+need to disable comparison in the @file{Makefile}.)
+If you do not want to bootstrap your compiler, you can configure with
+@option{--disable-bootstrap}.  In particular cases, you may want to
+bootstrap your compiler even if the target system is not the same as
+the one you are building on: for example, you could build a
+@code{powerpc-unknown-linux-gnu} toolchain on a
+@code{powerpc64-unknown-linux-gnu} host.  In this case, pass
+@option{--enable-bootstrap} to the configure script.
+@section Building a cross compiler
+When building a cross compiler, it is not generally possible to do a
+3-stage bootstrap of the compiler.  This makes for an interesting problem
+as parts of GCC can only be built with GCC@.
+To build a cross compiler, we first recommend building and installing a
+native compiler.  You can then use the native GCC compiler to build the
+cross compiler.  The installed native compiler needs to be GCC version
+2.95 or later.
+If the cross compiler is to be built with support for the Java
+programming language and the ability to compile .java source files is
+desired, the installed native compiler used to build the cross
+compiler needs to be the same GCC version as the cross compiler.  In
+addition the cross compiler needs to be configured with
+@option{--with-ecj-jar=@dots{}}.
+Assuming you have already installed a native copy of GCC and configured
+your cross compiler, issue the command @command{make}, which performs the
+following steps:
+@itemize @bullet
+@item
+Build host tools necessary to build the compiler.
+@item
+Build target tools for use by the compiler such as binutils (bfd,
+binutils, gas, gprof, ld, and opcodes)
+if they have been individually linked or moved into the top level GCC source
+tree before configuring.
+@item
+Build the compiler (single stage only).
+@item
+Build runtime libraries using the compiler from the previous step.
+@end itemize
+Note that if an error occurs in any step the make process will exit.
+If you are not building GNU binutils in the same source tree as GCC,
+you will need a cross-assembler and cross-linker installed before
+configuring GCC@.  Put them in the directory
+@file{@var{prefix}/@var{target}/bin}.  Here is a table of the tools
+you should put in this directory:
+@table @file
+@item as
+This should be the cross-assembler.
+@item ld
+This should be the cross-linker.
+@item ar
+This should be the cross-archiver: a program which can manipulate
+archive files (linker libraries) in the target machine's format.
+@item ranlib
+This should be a program to construct a symbol table in an archive file.
+@end table
+The installation of GCC will find these programs in that directory,
+and copy or link them to the proper place to for the cross-compiler to
+find them when run later.
+The easiest way to provide these files is to build the Binutils package.
+Configure it with the same @option{--host} and @option{--target}
+options that you use for configuring GCC, then build and install
+them.  They install their executables automatically into the proper
+directory.  Alas, they do not support all the targets that GCC
+supports.
+If you are not building a C library in the same source tree as GCC,
+you should also provide the target libraries and headers before
+configuring GCC, specifying the directories with
+@option{--with-sysroot} or @option{--with-headers} and
+@option{--with-libs}.  Many targets also require ``start files'' such
+as @file{crt0.o} and
+@file{crtn.o} which are linked into each executable.  There may be several
+alternatives for @file{crt0.o}, for use with profiling or other
+compilation options.  Check your target's definition of
+@code{STARTFILE_SPEC} to find out what start files it uses.
+@section Building in parallel
+GNU Make 3.79 and above, which is necessary to build GCC, support
+building in parallel.  To activate this, you can use @samp{make -j 2}
+instead of @samp{make}.  You can also specify a bigger number, and
+in most cases using a value greater than the number of processors in
+your machine will result in fewer and shorter I/O latency hits, thus
+improving overall throughput; this is especially true for slow drives
+and network filesystems.
+@section Building the Ada compiler
+In order to build GNAT, the Ada compiler, you need a working GNAT
+compiler (GCC version 3.4 or later).
+This includes GNAT tools such as @command{gnatmake} and
+@command{gnatlink}, since the Ada front end is written in Ada and
+uses some GNAT-specific extensions.
+In order to build a cross compiler, it is suggested to install
+the new compiler as native first, and then use it to build the cross
+compiler.
+@command{configure} does not test whether the GNAT installation works
+and has a sufficiently recent version; if too old a GNAT version is
+installed, the build will fail unless @option{--enable-languages} is
+used to disable building the Ada front end.
+@env{ADA_INCLUDE_PATH} and @env{ADA_OBJECT_PATH} environment variables
+must not be set when building the Ada compiler, the Ada tools, or the
+Ada runtime libraries. You can check that your build environment is clean
+by verifying that @samp{gnatls -v} lists only one explicit path in each
+section.
+@section Building with profile feedback
+It is possible to use profile feedback to optimize the compiler itself.  This
+should result in a faster compiler binary.  Experiments done on x86 using gcc
+3.3 showed approximately 7 percent speedup on compiling C programs.  To
+bootstrap the compiler with profile feedback, use @code{make profiledbootstrap}.
+When @samp{make profiledbootstrap} is run, it will first build a @code{stage1}
+compiler.  This compiler is used to build a @code{stageprofile} compiler
+instrumented to collect execution counts of instruction and branch
+probabilities.  Then runtime libraries are compiled with profile collected.
+Finally a @code{stagefeedback} compiler is built using the information collected.
+Unlike standard bootstrap, several additional restrictions apply.  The
+compiler used to build @code{stage1} needs to support a 64-bit integral type.
+It is recommended to only use GCC for this.  Also parallel make is currently
+not supported since collisions in profile collecting may occur.
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+@c ***Testing*****************************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Testing, Final install, Building, Installing GCC
+@end ifnothtml
+@ifset testhtml
+@ifnothtml
+@chapter Installing GCC: Testing
+@end ifnothtml
+@cindex Testing
+@cindex Installing GCC: Testing
+@cindex Testsuite
+Before you install GCC, we encourage you to run the testsuites and to
+compare your results with results from a similar configuration that have
+been submitted to the
+@uref{http://gcc.gnu.org/ml/gcc-testresults/,,gcc-testresults mailing list}.
+Some of these archived results are linked from the build status lists
+at @uref{http://gcc.gnu.org/buildstat.html}, although not everyone who
+reports a successful build runs the testsuites and submits the results.
+This step is optional and may require you to download additional software,
+but it can give you confidence in your new GCC installation or point out
+problems before you install and start using your new GCC@.
+First, you must have @uref{download.html,,downloaded the testsuites}.
+These are part of the full distribution, but if you downloaded the
+``core'' compiler plus any front ends, you must download the testsuites
+separately.
+Second, you must have the testing tools installed.  This includes
+@uref{http://www.gnu.org/software/dejagnu/,,DejaGnu}, Tcl, and Expect;
+the DejaGnu site has links to these.
+If the directories where @command{runtest} and @command{expect} were
+installed are not in the @env{PATH}, you may need to set the following
+environment variables appropriately, as in the following example (which
+assumes that DejaGnu has been installed under @file{/usr/local}):
+@smallexample
+TCL_LIBRARY = /usr/local/share/tcl8.0
+DEJAGNULIBS = /usr/local/share/dejagnu
+@end smallexample
+(On systems such as Cygwin, these paths are required to be actual
+paths, not mounts or links; presumably this is due to some lack of
+portability in the DejaGnu code.)
+Finally, you can run the testsuite (which may take a long time):
+@smallexample
+cd @var{objdir}; make -k check
+@end smallexample
+This will test various components of GCC, such as compiler
+front ends and runtime libraries.  While running the testsuite, DejaGnu
+might emit some harmless messages resembling
+@samp{WARNING: Couldn't find the global config file.} or
+@samp{WARNING: Couldn't find tool init file} that can be ignored.
+If you are testing a cross-compiler, you may want to run the testsuite
+on a simulator as described at @uref{http://gcc.gnu.org/simtest-howto.html}.
+@section How can you run the testsuite on selected tests?
+In order to run sets of tests selectively, there are targets
+@samp{make check-gcc} and @samp{make check-g++}
+in the @file{gcc} subdirectory of the object directory.  You can also
+just run @samp{make check} in a subdirectory of the object directory.
+A more selective way to just run all @command{gcc} execute tests in the
+testsuite is to use
+@smallexample
+make check-gcc RUNTESTFLAGS="execute.exp @var{other-options}"
+@end smallexample
+Likewise, in order to run only the @command{g++} ``old-deja'' tests in
+the testsuite with filenames matching @samp{9805*}, you would use
+@smallexample
+make check-g++ RUNTESTFLAGS="old-deja.exp=9805* @var{other-options}"
+@end smallexample
+The @file{*.exp} files are located in the testsuite directories of the GCC
+source, the most important ones being @file{compile.exp},
+@file{execute.exp}, @file{dg.exp} and @file{old-deja.exp}.
+To get a list of the possible @file{*.exp} files, pipe the
+output of @samp{make check} into a file and look at the
+@samp{Running @dots{}  .exp} lines.
+@section Passing options and running multiple testsuites
+You can pass multiple options to the testsuite using the
+@samp{--target_board} option of DejaGNU, either passed as part of
+@samp{RUNTESTFLAGS}, or directly to @command{runtest} if you prefer to
+work outside the makefiles.  For example,
+@smallexample
+make check-g++ RUNTESTFLAGS="--target_board=unix/-O3/-fmerge-constants"
+@end smallexample
+will run the standard @command{g++} testsuites (``unix'' is the target name
+for a standard native testsuite situation), passing
+@samp{-O3 -fmerge-constants} to the compiler on every test, i.e.,
+slashes separate options.
+You can run the testsuites multiple times using combinations of options
+with a syntax similar to the brace expansion of popular shells:
+@smallexample
+@dots{}"--target_board=arm-sim\@{-mhard-float,-msoft-float\@}\@{-O1,-O2,-O3,\@}"
+@end smallexample
+(Note the empty option caused by the trailing comma in the final group.)
+The following will run each testsuite eight times using the @samp{arm-sim}
+target, as if you had specified all possible combinations yourself:
+@smallexample
+--target_board=arm-sim/-mhard-float/-O1
+--target_board=arm-sim/-mhard-float/-O2
+--target_board=arm-sim/-mhard-float/-O3
+--target_board=arm-sim/-mhard-float
+--target_board=arm-sim/-msoft-float/-O1
+--target_board=arm-sim/-msoft-float/-O2
+--target_board=arm-sim/-msoft-float/-O3
+--target_board=arm-sim/-msoft-float
+@end smallexample
+They can be combined as many times as you wish, in arbitrary ways.  This
+list:
+@smallexample
+@dots{}"--target_board=unix/-Wextra\@{-O3,-fno-strength\@}\@{-fomit-frame,\@}"
+@end smallexample
+will generate four combinations, all involving @samp{-Wextra}.
+The disadvantage to this method is that the testsuites are run in serial,
+which is a waste on multiprocessor systems.  For users with GNU Make and
+a shell which performs brace expansion, you can run the testsuites in
+parallel by having the shell perform the combinations and @command{make}
+do the parallel runs.  Instead of using @samp{--target_board}, use a
+special makefile target:
+@smallexample
+make -j@var{N} check-@var{testsuite}//@var{test-target}/@var{option1}/@var{option2}/@dots{}
+@end smallexample
+For example,
+@smallexample
+make -j3 check-gcc//sh-hms-sim/@{-m1,-m2,-m3,-m3e,-m4@}/@{,-nofpu@}
+@end smallexample
+will run three concurrent ``make-gcc'' testsuites, eventually testing all
+ten combinations as described above.  Note that this is currently only
+supported in the @file{gcc} subdirectory.  (To see how this works, try
+typing @command{echo} before the example given here.)
+@section Additional testing for Java Class Libraries
+The Java runtime tests can be executed via @samp{make check}
+in the @file{@var{target}/libjava/testsuite} directory in
+the build tree.
+The @uref{http://sourceware.org/mauve/,,Mauve Project} provides
+a suite of tests for the Java Class Libraries.  This suite can be run
+as part of libgcj testing by placing the Mauve tree within the libjava
+testsuite at @file{libjava/testsuite/libjava.mauve/mauve}, or by
+specifying the location of that tree when invoking @samp{make}, as in
+@samp{make MAUVEDIR=~/mauve check}.
+@section How to interpret test results
+The result of running the testsuite are various @file{*.sum} and @file{*.log}
+files in the testsuite subdirectories.  The @file{*.log} files contain a
+detailed log of the compiler invocations and the corresponding
+results, the @file{*.sum} files summarize the results.  These summaries
+contain status codes for all tests:
+@itemize @bullet
+@item
+PASS: the test passed as expected
+@item
+XPASS: the test unexpectedly passed
+@item
+FAIL: the test unexpectedly failed
+@item
+XFAIL: the test failed as expected
+@item
+UNSUPPORTED: the test is not supported on this platform
+@item
+ERROR: the testsuite detected an error
+@item
+WARNING: the testsuite detected a possible problem
+@end itemize
+It is normal for some tests to report unexpected failures.  At the
+current time the testing harness does not allow fine grained control
+over whether or not a test is expected to fail.  This problem should
+be fixed in future releases.
+@section Submitting test results
+If you want to report the results to the GCC project, use the
+@file{contrib/test_summary} shell script.  Start it in the @var{objdir} with
+@smallexample
+@var{srcdir}/contrib/test_summary -p your_commentary.txt \
+-m gcc-testresults@@gcc.gnu.org |sh
+@end smallexample
+This script uses the @command{Mail} program to send the results, so
+make sure it is in your @env{PATH}.  The file @file{your_commentary.txt} is
+prepended to the testsuite summary and should contain any special
+remarks you have on your results or your build environment.  Please
+do not edit the testsuite result block or the subject line, as these
+messages may be automatically processed.
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+@c ***Final install***********************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Final install, , Testing, Installing GCC
+@end ifnothtml
+@ifset finalinstallhtml
+@ifnothtml
+@chapter Installing GCC: Final installation
+@end ifnothtml
+Now that GCC has been built (and optionally tested), you can install it with
+@smallexample
+cd @var{objdir}; make install
+@end smallexample
+We strongly recommend to install into a target directory where there is
+no previous version of GCC present.  Also, the GNAT runtime should not
+be stripped, as this would break certain features of the debugger that
+depend on this debugging information (catching Ada exceptions for
+instance).
+That step completes the installation of GCC; user level binaries can
+be found in @file{@var{prefix}/bin} where @var{prefix} is the value
+you specified with the @option{--prefix} to configure (or
+@file{/usr/local} by default).  (If you specified @option{--bindir},
+that directory will be used instead; otherwise, if you specified
+@option{--exec-prefix}, @file{@var{exec-prefix}/bin} will be used.)
+Headers for the C++ and Java libraries are installed in
+@file{@var{prefix}/include}; libraries in @file{@var{libdir}}
+(normally @file{@var{prefix}/lib}); internal parts of the compiler in
+@file{@var{libdir}/gcc} and @file{@var{libexecdir}/gcc}; documentation
+in info format in @file{@var{infodir}} (normally
+@file{@var{prefix}/info}).
+When installing cross-compilers, GCC's executables
+are not only installed into @file{@var{bindir}}, that
+is, @file{@var{exec-prefix}/bin}, but additionally into
+@file{@var{exec-prefix}/@var{target-alias}/bin}, if that directory
+exists.  Typically, such @dfn{tooldirs} hold target-specific
+binutils, including assembler and linker.
+Installation into a temporary staging area or into a @command{chroot}
+jail can be achieved with the command
+@smallexample
+make DESTDIR=@var{path-to-rootdir} install
+@end smallexample
+@noindent where @var{path-to-rootdir} is the absolute path of
+a directory relative to which all installation paths will be
+interpreted.  Note that the directory specified by @code{DESTDIR}
+need not exist yet; it will be created if necessary.
+There is a subtle point with tooldirs and @code{DESTDIR}:
+If you relocate a cross-compiler installation with
+e.g.@: @samp{DESTDIR=@var{rootdir}}, then the directory
+@file{@var{rootdir}/@var{exec-prefix}/@var{target-alias}/bin} will
+be filled with duplicated GCC executables only if it already exists,
+it will not be created otherwise.  This is regarded as a feature,
+not as a bug, because it gives slightly more control to the packagers
+using the @code{DESTDIR} feature.
+If you are bootstrapping a released version of GCC then please
+quickly review the build status page for your release, available from
+@uref{http://gcc.gnu.org/buildstat.html}.
+If your system is not listed for the version of GCC that you built,
+send a note to
+@email{gcc@@gcc.gnu.org} indicating
+that you successfully built and installed GCC@.
+Include the following information:
+@itemize @bullet
+@item
+Output from running @file{@var{srcdir}/config.guess}.  Do not send
+that file itself, just the one-line output from running it.
+@item
+The output of @samp{gcc -v} for your newly installed @command{gcc}.
+This tells us which version of GCC you built and the options you passed to
+configure.
+@item
+Whether you enabled all languages or a subset of them.  If you used a
+full distribution then this information is part of the configure
+options in the output of @samp{gcc -v}, but if you downloaded the
+``core'' compiler plus additional front ends then it isn't apparent
+which ones you built unless you tell us about it.
+@item
+If the build was for GNU/Linux, also include:
+@itemize @bullet
+@item
+The distribution name and version (e.g., Red Hat 7.1 or Debian 2.2.3);
+this information should be available from @file{/etc/issue}.
+@item
+The version of the Linux kernel, available from @samp{uname --version}
+or @samp{uname -a}.
+@item
+The version of glibc you used; for RPM-based systems like Red Hat,
+Mandrake, and SuSE type @samp{rpm -q glibc} to get the glibc version,
+and on systems like Debian and Progeny use @samp{dpkg -l libc6}.
+@end itemize
+For other systems, you can include similar information if you think it is
+relevant.
+@item
+Any other information that you think would be useful to people building
+GCC on the same configuration.  The new entry in the build status list
+will include a link to the archived copy of your message.
+@end itemize
+We'd also like to know if the
+@ifnothtml
+@ref{Specific, host/target specific installation notes}
+@end ifnothtml
+@ifhtml
+@uref{specific.html,,host/target specific installation notes}
+@end ifhtml
+didn't include your host/target information or if that information is
+incomplete or out of date.  Send a note to
+@email{gcc@@gcc.gnu.org} detailing how the information should be changed.
+If you find a bug, please report it following the
+@uref{../bugs.html,,bug reporting guidelines}.
+If you want to print the GCC manuals, do @samp{cd @var{objdir}; make
+dvi}.  You will need to have @command{texi2dvi} (version at least 4.7)
+and @TeX{} installed.  This creates a number of @file{.dvi} files in
+subdirectories of @file{@var{objdir}}; these may be converted for
+printing with programs such as @command{dvips}.  Alternately, by using
+@samp{make pdf} in place of @samp{make dvi}, you can create documentation
+in the form of @file{.pdf} files; this requires @command{texi2pdf}, which
+is included with Texinfo version 4.8 and later.  You can also
+@uref{http://www.gnu.org/order/order.html,,buy printed manuals from the
+Free Software Foundation}, though such manuals may not be for the most
+recent version of GCC@.
+If you would like to generate online HTML documentation, do @samp{cd
+@var{objdir}; make html} and HTML will be generated for the gcc manuals in
+@file{@var{objdir}/gcc/HTML}.
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+@c ***Binaries****************************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Binaries, Specific, Installing GCC, Top
+@end ifnothtml
+@ifset binarieshtml
+@ifnothtml
+@chapter Installing GCC: Binaries
+@end ifnothtml
+@cindex Binaries
+@cindex Installing GCC: Binaries
+We are often asked about pre-compiled versions of GCC@.  While we cannot
+provide these for all platforms, below you'll find links to binaries for
+various platforms where creating them by yourself is not easy due to various
+reasons.
+Please note that we did not create these binaries, nor do we
+support them.  If you have any problems installing them, please
+contact their makers.
+@itemize
+@item
+AIX:
+@itemize
+@item
+@uref{http://www.bullfreeware.com,,Bull's Freeware and Shareware Archive for AIX};
+@item
+@uref{http://pware.hvcc.edu,,Hudson Valley Community College Open Source Software for IBM System p};
+@item
+@uref{http://www.perzl.org/aix,,AIX 5L and 6 Open Source Packages}.
+@end itemize
+@item
+DOS---@uref{http://www.delorie.com/djgpp/,,DJGPP}.
+@item
+Renesas H8/300[HS]---@uref{http://h8300-hms.sourceforge.net/,,GNU
+Development Tools for the Renesas H8/300[HS] Series}.
+@item
+HP-UX:
+@itemize
+@item
+@uref{http://hpux.cs.utah.edu/,,HP-UX Porting Center};
+@item
+@uref{ftp://sunsite.informatik.rwth-aachen.de/pub/packages/gcc_hpux/,,Binaries for HP-UX 11.00 at Aachen University of Technology}.
+@end itemize
+@item
+Motorola 68HC11/68HC12---@uref{http://www.gnu-m68hc11.org,,GNU
+Development Tools for the Motorola 68HC11/68HC12}.
+@item
+@uref{http://www.sco.com/skunkware/devtools/index.html#gcc,,SCO
+OpenServer/Unixware}.
+@item
+Solaris 2 (SPARC, Intel)---@uref{http://www.sunfreeware.com/,,Sunfreeware}.
+@item
+SGI---@uref{http://freeware.sgi.com/,,SGI Freeware}.
+@item
+Microsoft Windows:
+@itemize
+@item
+The @uref{http://sourceware.org/cygwin/,,Cygwin} project;
+@item
+The @uref{http://www.mingw.org/,,MinGW} project.
+@end itemize
+@item
+@uref{ftp://ftp.thewrittenword.com/packages/by-name/,,The
+Written Word} offers binaries for
+AIX 4.3.3, 5.1 and 5.2,
+IRIX 6.5,
+Tru64 UNIX 4.0D and 5.1,
+GNU/Linux (i386),
+HP-UX 10.20, 11.00, and 11.11, and
+Solaris/SPARC 2.5.1, 2.6, 7, 8, 9 and 10.
+@item
+@uref{http://www.openpkg.org/,,OpenPKG} offers binaries for quite a
+number of platforms.
+@item
+The @uref{http://gcc.gnu.org/wiki/GFortranBinaries,,GFortran Wiki} has
+links to GNU Fortran binaries for several platforms.
+@end itemize
+In addition to those specific offerings, you can get a binary
+distribution CD-ROM from the
+@uref{http://www.gnu.org/order/order.html,,Free Software Foundation}.
+It contains binaries for a number of platforms, and
+includes not only GCC, but other stuff as well.  The current CD does
+not contain the latest version of GCC, but it should allow
+bootstrapping the compiler.  An updated version of that disk is in the
+works.
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+@c ***Specific****************************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Specific, Old, Binaries, Top
+@end ifnothtml
+@ifset specifichtml
+@ifnothtml
+@chapter Host/target specific installation notes for GCC
+@end ifnothtml
+@cindex Specific
+@cindex Specific installation notes
+@cindex Target specific installation
+@cindex Host specific installation
+@cindex Target specific installation notes
+Please read this document carefully @emph{before} installing the
+GNU Compiler Collection on your machine.
+Note that this list of install notes is @emph{not} a list of supported
+hosts or targets.  Not all supported hosts and targets are listed
+here, only the ones that require host-specific or target-specific
+information are.
+@ifhtml
+@itemize
+@item
+@uref{#alpha-x-x,,alpha*-*-*}
+@item
+@uref{#alpha-dec-osf,,alpha*-dec-osf*}
+@item
+@uref{#arc-x-elf,,arc-*-elf}
+@item
+@uref{#arm-x-elf,,arm-*-elf}
+@uref{#arm-x-coff,,arm-*-coff}
+@uref{#arm-x-aout,,arm-*-aout}
+@item
+@uref{#avr,,avr}
+@item
+@uref{#bfin,,Blackfin}
+@item
+@uref{#dos,,DOS}
+@item
+@uref{#x-x-freebsd,,*-*-freebsd*}
+@item
+@uref{#h8300-hms,,h8300-hms}
+@item
+@uref{#hppa-hp-hpux,,hppa*-hp-hpux*}
+@item
+@uref{#hppa-hp-hpux10,,hppa*-hp-hpux10}
+@item
+@uref{#hppa-hp-hpux11,,hppa*-hp-hpux11}
+@item
+@uref{#x-x-linux-gnu,,*-*-linux-gnu}
+@item
+@uref{#ix86-x-linux,,i?86-*-linux*}
+@item
+@uref{#ix86-x-solaris210,,i?86-*-solaris2.10}
+@item
+@uref{#ia64-x-linux,,ia64-*-linux}
+@item
+@uref{#ia64-x-hpux,,ia64-*-hpux*}
+@item
+@uref{#x-ibm-aix,,*-ibm-aix*}
+@item
+@uref{#iq2000-x-elf,,iq2000-*-elf}
+@item
+@uref{#m32c-x-elf,,m32c-*-elf}
+@item
+@uref{#m32r-x-elf,,m32r-*-elf}
+@item
+@uref{#m6811-elf,,m6811-elf}
+@item
+@uref{#m6812-elf,,m6812-elf}
+@item
+@uref{#m68k-x-x,,m68k-*-*}
+@item
+@uref{#m68k-uclinux,,m68k-uclinux}
+@item
+@uref{#mips-x-x,,mips-*-*}
+@item
+@uref{#mips-sgi-irix5,,mips-sgi-irix5}
+@item
+@uref{#mips-sgi-irix6,,mips-sgi-irix6}
+@item
+@uref{#powerpc-x-x,,powerpc*-*-*}
+@item
+@uref{#powerpc-x-darwin,,powerpc-*-darwin*}
+@item
+@uref{#powerpc-x-elf,,powerpc-*-elf}
+@item
+@uref{#powerpc-x-linux-gnu,,powerpc*-*-linux-gnu*}
+@item
+@uref{#powerpc-x-netbsd,,powerpc-*-netbsd*}
+@item
+@uref{#powerpc-x-eabisim,,powerpc-*-eabisim}
+@item
+@uref{#powerpc-x-eabi,,powerpc-*-eabi}
+@item
+@uref{#powerpcle-x-elf,,powerpcle-*-elf}
+@item
+@uref{#powerpcle-x-eabisim,,powerpcle-*-eabisim}
+@item
+@uref{#powerpcle-x-eabi,,powerpcle-*-eabi}
+@item
+@uref{#s390-x-linux,,s390-*-linux*}
+@item
+@uref{#s390x-x-linux,,s390x-*-linux*}
+@item
+@uref{#s390x-ibm-tpf,,s390x-ibm-tpf*}
+@item
+@uref{#x-x-solaris2,,*-*-solaris2*}
+@item
+@uref{#sparc-sun-solaris2,,sparc-sun-solaris2*}
+@item
+@uref{#sparc-sun-solaris27,,sparc-sun-solaris2.7}
+@item
+@uref{#sparc-x-linux,,sparc-*-linux*}
+@item
+@uref{#sparc64-x-solaris2,,sparc64-*-solaris2*}
+@item
+@uref{#sparcv9-x-solaris2,,sparcv9-*-solaris2*}
+@item
+@uref{#x-x-vxworks,,*-*-vxworks*}
+@item
+@uref{#x86-64-x-x,,x86_64-*-*, amd64-*-*}
+@item
+@uref{#xtensa-x-elf,,xtensa*-*-elf}
+@item
+@uref{#xtensa-x-linux,,xtensa*-*-linux*}
+@item
+@uref{#windows,,Microsoft Windows}
+@item
+@uref{#x-x-cygwin,,*-*-cygwin}
+@item
+@uref{#x-x-interix,,*-*-interix}
+@item
+@uref{#x-x-mingw,,*-*-mingw}
+@item
+@uref{#os2,,OS/2}
+@item
+@uref{#older,,Older systems}
+@end itemize
+@itemize
+@item
+@uref{#elf,,all ELF targets} (SVR4, Solaris 2, etc.)
+@end itemize
+@end ifhtml
+@html
+<!-- -------- host/target specific issues start here ---------------- -->
+<hr />
+@end html
+@heading @anchor{alpha-x-x}alpha*-*-*
+This section contains general configuration information for all
+alpha-based platforms using ELF (in particular, ignore this section for
+DEC OSF/1, Digital UNIX and Tru64 UNIX)@.  In addition to reading this
+section, please read all other sections that match your target.
+We require binutils 2.11.2 or newer.
+Previous binutils releases had a number of problems with DWARF 2
+debugging information, not the least of which is incorrect linking of
+shared libraries.
+@html
+<hr />
+@end html
+@heading @anchor{alpha-dec-osf}alpha*-dec-osf*
+Systems using processors that implement the DEC Alpha architecture and
+are running the DEC/Compaq Unix (DEC OSF/1, Digital UNIX, or Compaq
+Tru64 UNIX) operating system, for example the DEC Alpha AXP systems.
+As of GCC 3.2, versions before @code{alpha*-dec-osf4} are no longer
+supported.  (These are the versions which identify themselves as DEC
+OSF/1.)
+In Digital Unix V4.0, virtual memory exhausted bootstrap failures
+may be fixed by configuring with @option{--with-gc=simple},
+reconfiguring Kernel Virtual Memory and Swap parameters
+per the @command{/usr/sbin/sys_check} Tuning Suggestions,
+or applying the patch in
+@uref{http://gcc.gnu.org/ml/gcc/2002-08/msg00822.html}.
+In Tru64 UNIX V5.1, Compaq introduced a new assembler that does not
+currently (2001-06-13) work with @command{mips-tfile}.  As a workaround,
+we need to use the old assembler, invoked via the barely documented
+@option{-oldas} option.  To bootstrap GCC, you either need to use the
+Compaq C Compiler:
+@smallexample
+% CC=cc @var{srcdir}/configure [@var{options}] [@var{target}]
+@end smallexample
+or you can use a copy of GCC 2.95.3 or higher built on Tru64 UNIX V4.0:
+@smallexample
+% CC=gcc -Wa,-oldas @var{srcdir}/configure [@var{options}] [@var{target}]
+@end smallexample
+As of GNU binutils 2.11.2, neither GNU @command{as} nor GNU @command{ld}
+are supported on Tru64 UNIX, so you must not configure GCC with
+@option{--with-gnu-as} or @option{--with-gnu-ld}.
+GCC writes a @samp{.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 @file{/usr/include/stamp.h}.  If you install a
+new version of DEC Unix, you should rebuild GCC to pick up the new version
+stamp.
+@samp{make compare} may fail on old versions of DEC Unix unless you add
+@option{-save-temps} to @code{BOOT_CFLAGS}.  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 @code{stage1} and
+@code{stage2} compilations.  The option @option{-save-temps} forces a
+fixed name to be used for the assembler input file, instead of a
+randomly chosen name in @file{/tmp}.  Do not add @option{-save-temps}
+unless the comparisons fail without that option.  If you add
+@option{-save-temps}, you will have to manually delete the @samp{.i} and
+@samp{.s} files after each series of compilations.
+GCC 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 @option{--with-stabs} option of @file{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 @samp{.align} directive is used.  To work
+around this problem, GCC will not emit such alignment directives
+while writing ECOFF format debugging information even if optimization is
+being performed.  Unfortunately, this has the very undesirable
+side-effect that code addresses when @option{-O} is specified are
+different depending on whether or not @option{-g} is also specified.
+To avoid this behavior, specify @option{-gstabs+} and use GDB instead of
+DBX@.  DEC is now aware of this problem with the assembler and hopes to
+provide a fix shortly.
+@html
+<hr />
+@end html
+@heading @anchor{arc-x-elf}arc-*-elf
+Argonaut ARC processor.
+This configuration is intended for embedded systems.
+@html
+<hr />
+@end html
+@heading @anchor{arm-x-elf}arm-*-elf
+ARM-family processors.  Subtargets that use the ELF object format
+require GNU binutils 2.13 or newer.  Such subtargets include:
+@code{arm-*-freebsd}, @code{arm-*-netbsdelf}, @code{arm-*-*linux}
+and @code{arm-*-rtems}.
+@html
+<hr />
+@end html
+@heading @anchor{arm-x-coff}arm-*-coff
+ARM-family processors.  Note that there are two different varieties
+of PE format subtarget supported: @code{arm-wince-pe} and
+@code{arm-pe} as well as a standard COFF target @code{arm-*-coff}.
+@html
+<hr />
+@end html
+@heading @anchor{arm-x-aout}arm-*-aout
+ARM-family processors.  These targets support the AOUT file format:
+@code{arm-*-aout}, @code{arm-*-netbsd}.
+@html
+<hr />
+@end html
+@heading @anchor{avr}avr
+ATMEL AVR-family micro controllers.  These are used in embedded
+applications.  There are no standard Unix configurations.
+@ifnothtml
+@xref{AVR Options,, AVR Options, gcc, Using the GNU Compiler
+Collection (GCC)},
+@end ifnothtml
+@ifhtml
+See ``AVR Options'' in the main manual
+@end ifhtml
+for the list of supported MCU types.
+Use @samp{configure --target=avr --enable-languages="c"} to configure GCC@.
+Further installation notes and other useful information about AVR tools
+can also be obtained from:
+@itemize @bullet
+@item
+@uref{http://www.nongnu.org/avr/,,http://www.nongnu.org/avr/}
+@item
+@uref{http://home.overta.ru/users/denisc/,,http://home.overta.ru/users/denisc/}
+@item
+@uref{http://www.amelek.gda.pl/avr/,,http://www.amelek.gda.pl/avr/}
+@end itemize
+We @emph{strongly} recommend using binutils 2.13 or newer.
+The following error:
+@smallexample
+Error: register required
+@end smallexample
+indicates that you should upgrade to a newer version of the binutils.
+@html
+<hr />
+@end html
+@heading @anchor{bfin}Blackfin
+The Blackfin processor, an Analog Devices DSP.
+@ifnothtml
+@xref{Blackfin Options,, Blackfin Options, gcc, Using the GNU Compiler
+Collection (GCC)},
+@end ifnothtml
+@ifhtml
+See ``Blackfin Options'' in the main manual
+@end ifhtml
+More information, and a version of binutils with support for this processor,
+is available at @uref{http://blackfin.uclinux.org}
+@html
+<hr />
+@end html
+@heading @anchor{cris}CRIS
+CRIS is the CPU architecture in Axis Communications ETRAX system-on-a-chip
+series.  These are used in embedded applications.
+@ifnothtml
+@xref{CRIS Options,, CRIS Options, gcc, Using the GNU Compiler
+Collection (GCC)},
+@end ifnothtml
+@ifhtml
+See ``CRIS Options'' in the main manual
+@end ifhtml
+for a list of CRIS-specific options.
+There are a few different CRIS targets:
+@table @code
+@item cris-axis-elf
+Mainly for monolithic embedded systems.  Includes a multilib for the
+@samp{v10} core used in @samp{ETRAX 100 LX}.
+@item cris-axis-linux-gnu
+A GNU/Linux port for the CRIS architecture, currently targeting
+@samp{ETRAX 100 LX} by default.
+@end table
+For @code{cris-axis-elf} you need binutils 2.11
+or newer.  For @code{cris-axis-linux-gnu} you need binutils 2.12 or newer.
+Pre-packaged tools can be obtained from
+@uref{ftp://ftp.axis.com/pub/axis/tools/cris/compiler-kit/}.  More
+information about this platform is available at
+@uref{http://developer.axis.com/}.
+@html
+<hr />
+@end html
+@heading @anchor{crx}CRX
+The CRX CompactRISC architecture is a low-power 32-bit architecture with
+fast context switching and architectural extensibility features.
+@ifnothtml
+@xref{CRX Options,, CRX Options, gcc, Using and Porting the GNU Compiler
+Collection (GCC)},
+@end ifnothtml
+@ifhtml
+See ``CRX Options'' in the main manual for a list of CRX-specific options.
+@end ifhtml
+Use @samp{configure --target=crx-elf --enable-languages=c,c++} to configure
+GCC@ for building a CRX cross-compiler. The option @samp{--target=crx-elf}
+is also used to build the @samp{newlib} C library for CRX.
+It is also possible to build libstdc++-v3 for the CRX architecture. This
+needs to be done in a separate step with the following configure settings:
+@samp{gcc/libstdc++-v3/configure --host=crx-elf --with-newlib
+--enable-sjlj-exceptions --enable-cxx-flags='-fexceptions -frtti'}
+@html
+<hr />
+@end html
+@heading @anchor{dos}DOS
+Please have a look at the @uref{binaries.html,,binaries page}.
+You cannot install GCC 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.
+@html
+<hr />
+@end html
+@heading @anchor{x-x-freebsd}*-*-freebsd*
+The version of binutils installed in @file{/usr/bin} probably works with
+this release of GCC@.  However, on FreeBSD 4, bootstrapping against the
+latest FSF binutils is known to improve overall testsuite results; and,
+on FreeBSD/alpha, using binutils 2.14 or later is required to build libjava.
+Support for FreeBSD 1 was discontinued in GCC 3.2.
+Support for FreeBSD 2 will be discontinued after GCC 3.4.  The
+following was true for GCC 3.1 but the current status is unknown.
+For FreeBSD 2 or any mutant a.out versions of FreeBSD 3: All
+configuration support and files as shipped with GCC 2.95 are still in
+place.  FreeBSD 2.2.7 has been known to bootstrap completely; however,
+it is unknown which version of binutils was used (it is assumed that it
+was the system copy in @file{/usr/bin}) and C++ EH failures were noted.
+For FreeBSD using the ELF file format: DWARF 2 debugging is now the
+default for all CPU architectures.  It had been the default on
+FreeBSD/alpha since its inception.  You may use @option{-gstabs} instead
+of @option{-g}, if you really want the old debugging format.  There are
+no known issues with mixing object files and libraries with different
+debugging formats.  Otherwise, this release of GCC should now match more
+of the configuration used in the stock FreeBSD configuration of GCC@.  In
+particular, @option{--enable-threads} is now configured by default.
+However, as a general user, do not attempt to replace the system
+compiler with this release.  Known to bootstrap and check with good
+results on FreeBSD 4.9-STABLE and 5-CURRENT@.  In the past, known to
+bootstrap and check with good results on FreeBSD 3.0, 3.4, 4.0, 4.2,
+4.3, 4.4, 4.5, 4.8-STABLE@.
+In principle, @option{--enable-threads} is now compatible with
+@option{--enable-libgcj} on FreeBSD@.  However, it has only been built
+and tested on @samp{i386-*-freebsd[45]} and @samp{alpha-*-freebsd[45]}.
+The static
+library may be incorrectly built (symbols are missing at link time).
+There is a rare timing-based startup hang (probably involves an
+assumption about the thread library).  Multi-threaded boehm-gc (required for
+libjava) exposes severe threaded signal-handling bugs on FreeBSD before
+4.5-RELEASE@.  Other CPU architectures
+supported by FreeBSD will require additional configuration tuning in, at
+the very least, both boehm-gc and libffi.
+Shared @file{libgcc_s.so} is now built and installed by default.
+@html
+<hr />
+@end html
+@heading @anchor{h8300-hms}h8300-hms
+Renesas H8/300 series of processors.
+Please have a look at the @uref{binaries.html,,binaries page}.
+The calling convention and structure layout has changed in release 2.6.
+All code must be recompiled.  The calling convention now passes the
+first three arguments in function calls in registers.  Structures are no
+longer a multiple of 2 bytes.
+@html
+<hr />
+@end html
+@heading @anchor{hppa-hp-hpux}hppa*-hp-hpux*
+Support for HP-UX version 9 and older was discontinued in GCC 3.4.
+We require using gas/binutils on all hppa platforms.  Version 2.19 or
+later is recommended.
+It may be helpful to configure GCC with the
+@uref{./configure.html#with-gnu-as,,@option{--with-gnu-as}} and
+@option{--with-as=@dots{}} options to ensure that GCC can find GAS@.
+The HP assembler should not be used with GCC.  It is rarely tested and may
+not work.  It shouldn't be used with any languages other than C due to its
+many limitations.
+Specifically, @option{-g} does not work (HP-UX uses a peculiar debugging
+format which GCC does not know about).  It also inserts timestamps
+into each object file it creates, causing the 3-stage comparison test to
+fail during a bootstrap.  You should be able to continue by saying
+@samp{make all-host all-target} after getting the failure from @samp{make}.
+Various GCC features are not supported.  For example, it does not support weak
+symbols or alias definitions.  As a result, explicit template instantiations
+are required when using C++.  This makes it difficult if not impossible to
+build many C++ applications.
+There are two default scheduling models for instructions.  These are
+PROCESSOR_7100LC and PROCESSOR_8000.  They are selected from the pa-risc
+architecture specified for the target machine when configuring.
+PROCESSOR_8000 is the default.  PROCESSOR_7100LC is selected when
+the target is a @samp{hppa1*} machine.
+The PROCESSOR_8000 model is not well suited to older processors.  Thus,
+it is important to completely specify the machine architecture when
+configuring if you want a model other than PROCESSOR_8000.  The macro
+TARGET_SCHED_DEFAULT can be defined in BOOT_CFLAGS if a different
+default scheduling model is desired.
+As of GCC 4.0, GCC uses the UNIX 95 namespace for HP-UX 10.10
+through 11.00, and the UNIX 98 namespace for HP-UX 11.11 and later.
+This namespace change might cause problems when bootstrapping with
+an earlier version of GCC or the HP compiler as essentially the same
+namespace is required for an entire build.  This problem can be avoided
+in a number of ways.  With HP cc, @env{UNIX_STD} can be set to @samp{95}
+or @samp{98}.  Another way is to add an appropriate set of predefines
+to @env{CC}.  The description for the @option{munix=} option contains
+a list of the predefines used with each standard.
+More specific information to @samp{hppa*-hp-hpux*} targets follows.
+@html
+<hr />
+@end html
+@heading @anchor{hppa-hp-hpux10}hppa*-hp-hpux10
+For hpux10.20, we @emph{highly} recommend you pick up the latest sed patch
+@code{PHCO_19798} from HP@.  HP has two sites which provide patches free of
+charge:
+@itemize @bullet
+@item
+@html
+<a href="http://us.itrc.hp.com/service/home/home.do">US, Canada, Asia-Pacific, and
+Latin-America</a>
+@end html
+@ifnothtml
+@uref{http://us.itrc.hp.com/service/home/home.do,,} US, Canada, Asia-Pacific,
+and Latin-America.
+@end ifnothtml
+@item
+@uref{http://europe.itrc.hp.com/service/home/home.do,,} Europe.
+@end itemize
+The C++ ABI has changed incompatibly in GCC 4.0.  COMDAT subspaces are
+used for one-only code and data.  This resolves many of the previous
+problems in using C++ on this target.  However, the ABI is not compatible
+with the one implemented under HP-UX 11 using secondary definitions.
+@html
+<hr />
+@end html
+@heading @anchor{hppa-hp-hpux11}hppa*-hp-hpux11
+GCC 3.0 and up support HP-UX 11.  GCC 2.95.x is not supported and cannot
+be used to compile GCC 3.0 and up.
+The libffi and libjava libraries haven't been ported to 64-bit HP-UX@
+and don't build.
+Refer to @uref{binaries.html,,binaries} for information about obtaining
+precompiled GCC binaries for HP-UX@.  Precompiled binaries must be obtained
+to build the Ada language as it can't be bootstrapped using C@.  Ada is
+only available for the 32-bit PA-RISC runtime.
+Starting with GCC 3.4 an ISO C compiler is required to bootstrap.  The
+bundled compiler supports only traditional C; you will need either HP's
+unbundled compiler, or a binary distribution of GCC@.
+It is possible to build GCC 3.3 starting with the bundled HP compiler,
+but the process requires several steps.  GCC 3.3 can then be used to
+build later versions.  The fastjar program contains ISO C code and
+can't be built with the HP bundled compiler.  This problem can be
+avoided by not building the Java language.  For example, use the
+@option{--enable-languages="c,c++,f77,objc"} option in your configure
+command.
+There are several possible approaches to building the distribution.
+Binutils can be built first using the HP tools.  Then, the GCC
+distribution can be built.  The second approach is to build GCC
+first using the HP tools, then build binutils, then rebuild GCC@.
+There have been problems with various binary distributions, so it
+is best not to start from a binary distribution.
+On 64-bit capable systems, there are two distinct targets.  Different
+installation prefixes must be used if both are to be installed on
+the same system.  The @samp{hppa[1-2]*-hp-hpux11*} target generates code
+for the 32-bit PA-RISC runtime architecture and uses the HP linker.
+The @samp{hppa64-hp-hpux11*} target generates 64-bit code for the
+PA-RISC 2.0 architecture.
+The script config.guess now selects the target type based on the compiler
+detected during configuration.  You must define @env{PATH} or @env{CC} so
+that configure finds an appropriate compiler for the initial bootstrap.
+When @env{CC} is used, the definition should contain the options that are
+needed whenever @env{CC} is used.
+Specifically, options that determine the runtime architecture must be
+in @env{CC} to correctly select the target for the build.  It is also
+convenient to place many other compiler options in @env{CC}.  For example,
+@env{CC="cc -Ac +DA2.0W -Wp,-H16376 -D_CLASSIC_TYPES -D_HPUX_SOURCE"}
+can be used to bootstrap the GCC 3.3 branch with the HP compiler in
+64-bit K&R/bundled mode.  The @option{+DA2.0W} option will result in
+the automatic selection of the @samp{hppa64-hp-hpux11*} target.  The
+macro definition table of cpp needs to be increased for a successful
+build with the HP compiler.  _CLASSIC_TYPES and _HPUX_SOURCE need to
+be defined when building with the bundled compiler, or when using the
+@option{-Ac} option.  These defines aren't necessary with @option{-Ae}.
+It is best to explicitly configure the @samp{hppa64-hp-hpux11*} target
+with the @option{--with-ld=@dots{}} option.  This overrides the standard
+search for ld.  The two linkers supported on this target require different
+commands.  The default linker is determined during configuration.  As a
+result, it's not possible to switch linkers in the middle of a GCC build.
+This has been reported to sometimes occur in unified builds of binutils
+and GCC@.
+A recent linker patch must be installed for the correct operation of
+GCC 3.3 and later.  @code{PHSS_26559} and @code{PHSS_24304} are the
+oldest linker patches that are known to work.  They are for HP-UX
+11.00 and 11.11, respectively.  @code{PHSS_24303}, the companion to
+@code{PHSS_24304}, might be usable but it hasn't been tested.  These
+patches have been superseded.  Consult the HP patch database to obtain
+the currently recommended linker patch for your system.
+The patches are necessary for the support of weak symbols on the
+32-bit port, and for the running of initializers and finalizers.  Weak
+symbols are implemented using SOM secondary definition symbols.  Prior
+to HP-UX 11, there are bugs in the linker support for secondary symbols.
+The patches correct a problem of linker core dumps creating shared
+libraries containing secondary symbols, as well as various other
+linking issues involving secondary symbols.
+GCC 3.3 uses the ELF DT_INIT_ARRAY and DT_FINI_ARRAY capabilities to
+run initializers and finalizers on the 64-bit port.  The 32-bit port
+uses the linker @option{+init} and @option{+fini} options for the same
+purpose.  The patches correct various problems with the +init/+fini
+options, including program core dumps.  Binutils 2.14 corrects a
+problem on the 64-bit port resulting from HP's non-standard use of
+the .init and .fini sections for array initializers and finalizers.
+Although the HP and GNU linkers are both supported for the
+@samp{hppa64-hp-hpux11*} target, it is strongly recommended that the
+HP linker be used for link editing on this target.
+At this time, the GNU linker does not support the creation of long
+branch stubs.  As a result, it can't successfully link binaries
+containing branch offsets larger than 8 megabytes.  In addition,
+there are problems linking shared libraries, linking executables
+with @option{-static}, and with dwarf2 unwind and exception support.
+It also doesn't provide stubs for internal calls to global functions
+in shared libraries, so these calls can't be overloaded.
+The HP dynamic loader does not support GNU symbol versioning, so symbol
+versioning is not supported.  It may be necessary to disable symbol
+versioning with @option{--disable-symvers} when using GNU ld.
+POSIX threads are the default.  The optional DCE thread library is not
+supported, so @option{--enable-threads=dce} does not work.
+@html
+<hr />
+@end html
+@heading @anchor{x-x-linux-gnu}*-*-linux-gnu
+Versions of libstdc++-v3 starting with 3.2.1 require bug fixes present
+in glibc 2.2.5 and later.  More information is available in the
+libstdc++-v3 documentation.
+@html
+<hr />
+@end html
+@heading @anchor{ix86-x-linux}i?86-*-linux*
+As of GCC 3.3, binutils 2.13.1 or later is required for this platform.
+See @uref{http://gcc.gnu.org/PR10877,,bug 10877} for more information.
+If you receive Signal 11 errors when building on GNU/Linux, then it is
+possible you have a hardware problem.  Further information on this can be
+found on @uref{http://www.bitwizard.nl/sig11/,,www.bitwizard.nl}.
+@html
+<hr />
+@end html
+@heading @anchor{ix86-x-solaris210}i?86-*-solaris2.10
+Use this for Solaris 10 or later on x86 and x86-64 systems.  This
+configuration is supported by GCC 4.0 and later versions only.
+It is recommended that you configure GCC to use the GNU assembler in
+@file{/usr/sfw/bin/gas} but the Sun linker, using the options
+@option{--with-gnu-as --with-as=/usr/sfw/bin/gas --without-gnu-ld
+--with-ld=/usr/ccs/bin/ld}.
+@html
+<hr />
+@end html
+@heading @anchor{ia64-x-linux}ia64-*-linux
+IA-64 processor (also known as IPF, or Itanium Processor Family)
+running GNU/Linux.
+If you are using the installed system libunwind library with
+@option{--with-system-libunwind}, then you must use libunwind 0.98 or
+later.
+None of the following versions of GCC has an ABI that is compatible
+with any of the other versions in this list, with the exception that
+Red Hat 2.96 and Trillian 000171 are compatible with each other:
+3.1, 3.0.2, 3.0.1, 3.0, Red Hat 2.96, and Trillian 000717.
+This primarily affects C++ programs and programs that create shared libraries.
+GCC 3.1 or later is recommended for compiling linux, the kernel.
+As of version 3.1 GCC is believed to be fully ABI compliant, and hence no
+more major ABI changes are expected.
+@html
+<hr />
+@end html
+@heading @anchor{ia64-x-hpux}ia64-*-hpux*
+Building GCC on this target requires the GNU Assembler.  The bundled HP
+assembler will not work.  To prevent GCC from using the wrong assembler,
+the option @option{--with-gnu-as} may be necessary.
+The GCC libunwind library has not been ported to HPUX@.  This means that for
+GCC versions 3.2.3 and earlier, @option{--enable-libunwind-exceptions}
+is required to build GCC@.  For GCC 3.3 and later, this is the default.
+For gcc 3.4.3 and later, @option{--enable-libunwind-exceptions} is
+removed and the system libunwind library will always be used.
+@html
+<hr />
+<!-- rs6000-ibm-aix*, powerpc-ibm-aix* -->
+@end html
+@heading @anchor{x-ibm-aix}*-ibm-aix*
+Support for AIX version 3 and older was discontinued in GCC 3.4.
+``out of memory'' bootstrap failures may indicate a problem with
+process resource limits (ulimit).  Hard limits are configured in the
+@file{/etc/security/limits} system configuration file.
+To speed up the configuration phases of bootstrapping and installing GCC,
+one may use GNU Bash instead of AIX @command{/bin/sh}, e.g.,
+@smallexample
+% CONFIG_SHELL=/opt/freeware/bin/bash
+% export CONFIG_SHELL
+@end smallexample
+and then proceed as described in @uref{build.html,,the build
+instructions}, where we strongly recommend specifying an absolute path
+to invoke @var{srcdir}/configure.
+Because GCC on AIX is built as a 32-bit executable by default,
+(although it can generate 64-bit programs) the GMP and MPFR libraries
+required by gfortran must be 32-bit libraries.  Building GMP and MPFR
+as static archive libraries works better than shared libraries.
+Errors involving @code{alloca} when building GCC generally are due
+to an incorrect definition of @code{CC} in the Makefile or mixing files
+compiled with the native C compiler and GCC@.  During the stage1 phase of
+the build, the native AIX compiler @strong{must} be invoked as @command{cc}
+(not @command{xlc}).  Once @command{configure} has been informed of
+@command{xlc}, one needs to use @samp{make distclean} to remove the
+configure cache files and ensure that @env{CC} environment variable
+does not provide a definition that will confuse @command{configure}.
+If this error occurs during stage2 or later, then the problem most likely
+is the version of Make (see above).
+The native @command{as} and @command{ld} are recommended for bootstrapping
+on AIX 4 and required for bootstrapping on AIX 5L@.  The GNU Assembler
+reports that it supports WEAK symbols on AIX 4, which causes GCC to try to
+utilize weak symbol functionality although it is not supported.  The GNU
+Assembler and Linker do not support AIX 5L sufficiently to bootstrap GCC@.
+The native AIX tools do interoperate with GCC@.
+Building @file{libstdc++.a} requires a fix for an AIX Assembler bug
+APAR IY26685 (AIX 4.3) or APAR IY25528 (AIX 5.1).  It also requires a
+fix for another AIX Assembler bug and a co-dependent AIX Archiver fix
+referenced as APAR IY53606 (AIX 5.2) or a APAR IY54774 (AIX 5.1)
+@samp{libstdc++} in GCC 3.4 increments the major version number of the
+shared object and GCC installation places the @file{libstdc++.a}
+shared library in a common location which will overwrite the and GCC
+3.3 version of the shared library.  Applications either need to be
+re-linked against the new shared library or the GCC 3.1 and GCC 3.3
+versions of the @samp{libstdc++} shared object needs to be available
+to the AIX runtime loader.  The GCC 3.1 @samp{libstdc++.so.4}, if
+present, and GCC 3.3 @samp{libstdc++.so.5} shared objects can be
+installed for runtime dynamic loading using the following steps to set
+the @samp{F_LOADONLY} flag in the shared object for @emph{each}
+multilib @file{libstdc++.a} installed:
+Extract the shared objects from the currently installed
+@file{libstdc++.a} archive:
+@smallexample
+% ar -x libstdc++.a libstdc++.so.4 libstdc++.so.5
+@end smallexample
+Enable the @samp{F_LOADONLY} flag so that the shared object will be
+available for runtime dynamic loading, but not linking:
+@smallexample
+% strip -e libstdc++.so.4 libstdc++.so.5
+@end smallexample
+Archive the runtime-only shared object in the GCC 3.4
+@file{libstdc++.a} archive:
+@smallexample
+% ar -q libstdc++.a libstdc++.so.4 libstdc++.so.5
+@end smallexample
+Linking executables and shared libraries may produce warnings of
+duplicate symbols.  The assembly files generated by GCC for AIX always
+have included multiple symbol definitions for certain global variable
+and function declarations in the original program.  The warnings should
+not prevent the linker from producing a correct library or runnable
+executable.
+AIX 4.3 utilizes a ``large format'' archive to support both 32-bit and
+64-bit object modules.  The routines provided in AIX 4.3.0 and AIX 4.3.1
+to parse archive libraries did not handle the new format correctly.
+These routines are used by GCC and result in error messages during
+linking such as ``not a COFF file''.  The version of the routines shipped
+with AIX 4.3.1 should work for a 32-bit environment.  The @option{-g}
+option of the archive command may be used to create archives of 32-bit
+objects using the original ``small format''.  A correct version of the
+routines is shipped with AIX 4.3.2 and above.
+Some versions of the AIX binder (linker) can fail with a relocation
+overflow severe error when the @option{-bbigtoc} option is used to link
+GCC-produced object files into an executable that overflows the TOC@.  A fix
+for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is
+available from IBM Customer Support and from its
+@uref{http://techsupport.services.ibm.com/,,techsupport.services.ibm.com}
+website as PTF U455193.
+The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core
+with a segmentation fault when invoked by any version of GCC@.  A fix for
+APAR IX87327 is available from IBM Customer Support and from its
+@uref{http://techsupport.services.ibm.com/,,techsupport.services.ibm.com}
+website as PTF U461879.  This fix is incorporated in AIX 4.3.3 and above.
+The initial assembler shipped with AIX 4.3.0 generates incorrect object
+files.  A fix for APAR IX74254 (64BIT DISASSEMBLED OUTPUT FROM COMPILER FAILS
+TO ASSEMBLE/BIND) is available from IBM Customer Support and from its
+@uref{http://techsupport.services.ibm.com/,,techsupport.services.ibm.com}
+website as PTF U453956.  This fix is incorporated in AIX 4.3.1 and above.
+AIX provides National Language Support (NLS)@.  Compilers and assemblers
+use NLS to support locale-specific representations of various data
+formats including floating-point numbers (e.g., @samp{.}  vs @samp{,} for
+separating decimal fractions).  There have been problems reported where
+GCC does not produce the same floating-point formats that the assembler
+expects.  If one encounters this problem, set the @env{LANG}
+environment variable to @samp{C} or @samp{En_US}.
+By default, GCC for AIX 4.1 and above produces code that can be used on
+both Power or PowerPC processors.
+A default can be specified with the @option{-mcpu=@var{cpu_type}}
+switch and using the configure option @option{--with-cpu-@var{cpu_type}}.
+@html
+<hr />
+@end html
+@heading @anchor{iq2000-x-elf}iq2000-*-elf
+Vitesse IQ2000 processors.  These are used in embedded
+applications.  There are no standard Unix configurations.
+@html
+<hr />
+@end html
+@heading @anchor{m32c-x-elf}m32c-*-elf
+Renesas M32C processor.
+This configuration is intended for embedded systems.
+@html
+<hr />
+@end html
+@heading @anchor{m32r-x-elf}m32r-*-elf
+Renesas M32R processor.
+This configuration is intended for embedded systems.
+@html
+<hr />
+@end html
+@heading @anchor{m6811-elf}m6811-elf
+Motorola 68HC11 family micro controllers.  These are used in embedded
+applications.  There are no standard Unix configurations.
+@html
+<hr />
+@end html
+@heading @anchor{m6812-elf}m6812-elf
+Motorola 68HC12 family micro controllers.  These are used in embedded
+applications.  There are no standard Unix configurations.
+@html
+<hr />
+@end html
+@heading @anchor{m68k-x-x}m68k-*-*
+By default, @samp{m68k-*-aout}, @samp{m68k-*-coff*},
+@samp{m68k-*-elf*}, @samp{m68k-*-rtems},  @samp{m68k-*-uclinux} and
+@samp{m68k-*-linux}
+build libraries for both M680x0 and ColdFire processors.  If you only
+need the M680x0 libraries, you can omit the ColdFire ones by passing
+@option{--with-arch=m68k} to @command{configure}.  Alternatively, you
+can omit the M680x0 libraries by passing @option{--with-arch=cf} to
+@command{configure}.  These targets default to 5206 or 5475 code as
+appropriate for the target system when
+configured with @option{--with-arch=cf} and 68020 code otherwise.
+The @samp{m68k-*-netbsd} and
+@samp{m68k-*-openbsd} targets also support the @option{--with-arch}
+option.  They will generate ColdFire CFV4e code when configured with
+@option{--with-arch=cf} and 68020 code otherwise.
+You can override the default processors listed above by configuring
+with @option{--with-cpu=@var{target}}.  This @var{target} can either
+be a @option{-mcpu} argument or one of the following values:
+@samp{m68000}, @samp{m68010}, @samp{m68020}, @samp{m68030},
+@samp{m68040}, @samp{m68060}, @samp{m68020-40} and @samp{m68020-60}.
+@html
+<hr />
+@end html
+@heading @anchor{m68k-x-uclinux}m68k-*-uclinux
+GCC 4.3 changed the uClinux configuration so that it uses the
+@samp{m68k-linux-gnu} ABI rather than the @samp{m68k-elf} ABI.
+It also added improved support for C++ and flat shared libraries,
+both of which were ABI changes.  However, you can still use the
+original ABI by configuring for @samp{m68k-uclinuxoldabi} or
+@samp{m68k-@var{vendor}-uclinuxoldabi}.
+@html
+<hr />
+@end html
+@heading @anchor{mips-x-x}mips-*-*
+If on a MIPS system you get an error message saying ``does not have gp
+sections for all it's [sic] sectons [sic]'', don't worry about it.  This
+happens whenever you use GAS with the MIPS linker, but there is not
+really anything wrong, and it is okay to use the output file.  You can
+stop such warnings by installing the GNU linker.
+It would be nice to extend GAS to produce the gp tables, but they are
+optional, and there should not be a warning about their absence.
+The libstdc++ atomic locking routines for MIPS targets requires MIPS II
+and later.  A patch went in just after the GCC 3.3 release to
+make @samp{mips*-*-*} use the generic implementation instead.  You can also
+configure for @samp{mipsel-elf} as a workaround.  The
+@samp{mips*-*-linux*} target continues to use the MIPS II routines.  More
+work on this is expected in future releases.
+@c If you make --with-llsc the default for another target, please also
+@c update the description of the --with-llsc option.
+The built-in @code{__sync_*} functions are available on MIPS II and
+later systems and others that support the @samp{ll}, @samp{sc} and
+@samp{sync} instructions.  This can be overridden by passing
+@option{--with-llsc} or @option{--without-llsc} when configuring GCC.
+Since the Linux kernel emulates these instructions if they are
+missing, the default for @samp{mips*-*-linux*} targets is
+@option{--with-llsc}.  The @option{--with-llsc} and
+@option{--without-llsc} configure options may be overridden at compile
+time by passing the @option{-mllsc} or @option{-mno-llsc} options to
+the compiler.
+MIPS systems check for division by zero (unless
+@option{-mno-check-zero-division} is passed to the compiler) by
+generating either a conditional trap or a break instruction.  Using
+trap results in smaller code, but is only supported on MIPS II and
+later.  Also, some versions of the Linux kernel have a bug that
+prevents trap from generating the proper signal (@code{SIGFPE}).  To enable
+the use of break, use the @option{--with-divide=breaks}
+@command{configure} option when configuring GCC@.  The default is to
+use traps on systems that support them.
+Cross-compilers for the MIPS as target using the MIPS assembler
+currently do not work, because the auxiliary programs
+@file{mips-tdump.c} and @file{mips-tfile.c} can't be compiled on
+anything but a MIPS@.  It does work to cross compile for a MIPS
+if you use the GNU assembler and linker.
+The assembler from GNU binutils 2.17 and earlier has a bug in the way
+it sorts relocations for REL targets (o32, o64, EABI).  This can cause
+bad code to be generated for simple C++ programs.  Also the linker
+from GNU binutils versions prior to 2.17 has a bug which causes the
+runtime linker stubs in very large programs, like @file{libgcj.so}, to
+be incorrectly generated.  GNU Binutils 2.18 and later (and snapshots
+made after Nov. 9, 2006) should be free from both of these problems.
+@html
+<hr />
+@end html
+@heading @anchor{mips-sgi-irix5}mips-sgi-irix5
+In order to compile GCC on an SGI running IRIX 5, the @samp{compiler_dev.hdr}
+subsystem must be installed from the IDO CD-ROM supplied by SGI@.
+It is also available for download from
+@uref{ftp://ftp.sgi.com/sgi/IRIX5.3/iris-development-option-5.3.tardist}.
+If you use the MIPS C compiler to bootstrap, it may be necessary
+to increase its table size for switch statements with the
+@option{-Wf,-XNg1500} option.  If you use the @option{-O2}
+optimization option, you also need to use @option{-Olimit 3000}.
+To enable debugging under IRIX 5, you must use GNU binutils 2.15 or
+later, and use the @option{--with-gnu-ld} @command{configure} option
+when configuring GCC@.  You need to use GNU @command{ar} and @command{nm},
+also distributed with GNU binutils.
+Some users have reported that @command{/bin/sh} will hang during bootstrap.
+This problem can be avoided by running the commands:
+@smallexample
+% CONFIG_SHELL=/bin/ksh
+% export CONFIG_SHELL
+@end smallexample
+before starting the build.
+@html
+<hr />
+@end html
+@heading @anchor{mips-sgi-irix6}mips-sgi-irix6
+If you are using SGI's MIPSpro @command{cc} as your bootstrap compiler, you must
+ensure that the N32 ABI is in use.  To test this, compile a simple C
+file with @command{cc} and then run @command{file} on the
+resulting object file.  The output should look like:
+@smallexample
+test.o: ELF N32 MSB @dots{}
+@end smallexample
+If you see:
+@smallexample
+test.o: ELF 32-bit MSB @dots{}
+@end smallexample
+or
+@smallexample
+test.o: ELF 64-bit MSB @dots{}
+@end smallexample
+then your version of @command{cc} uses the O32 or N64 ABI by default.  You
+should set the environment variable @env{CC} to @samp{cc -n32}
+before configuring GCC@.
+If you want the resulting @command{gcc} to run on old 32-bit systems
+with the MIPS R4400 CPU, you need to ensure that only code for the @samp{mips3}
+instruction set architecture (ISA) is generated.  While GCC 3.x does
+this correctly, both GCC 2.95 and SGI's MIPSpro @command{cc} may change
+the ISA depending on the machine where GCC is built.  Using one of them
+as the bootstrap compiler may result in @samp{mips4} code, which won't run at
+all on @samp{mips3}-only systems.  For the test program above, you should see:
+@smallexample
+test.o: ELF N32 MSB mips-3 @dots{}
+@end smallexample
+If you get:
+@smallexample
+test.o: ELF N32 MSB mips-4 @dots{}
+@end smallexample
+instead, you should set the environment variable @env{CC} to @samp{cc
+-n32 -mips3} or @samp{gcc -mips3} respectively before configuring GCC@.
+MIPSpro C 7.4 may cause bootstrap failures, due to a bug when inlining
+@code{memcmp}.  Either add @code{-U__INLINE_INTRINSICS} to the @env{CC}
+environment variable as a workaround or upgrade to MIPSpro C 7.4.1m.
+GCC on IRIX 6 is usually built to support the N32, O32 and N64 ABIs.  If
+you build GCC on a system that doesn't have the N64 libraries installed
+or cannot run 64-bit binaries,
+you need to configure with @option{--disable-multilib} so GCC doesn't
+try to use them.  This will disable building the O32 libraries, too.
+Look for @file{/usr/lib64/libc.so.1} to see if you
+have the 64-bit libraries installed.
+To enable debugging for the O32 ABI, you must use GNU @command{as} from
+GNU binutils 2.15 or later.  You may also use GNU @command{ld}, but
+this is not required and currently causes some problems with Ada.
+The @option{--enable-libgcj}
+option is disabled by default: IRIX 6 uses a very low default limit
+(20480) for the command line length.  Although @command{libtool} contains a
+workaround for this problem, at least the N64 @samp{libgcj} is known not
+to build despite this, running into an internal error of the native
+@command{ld}.  A sure fix is to increase this limit (@samp{ncargs}) to
+its maximum of 262144 bytes.  If you have root access, you can use the
+@command{systune} command to do this.
+@code{wchar_t} support in @samp{libstdc++} is not available for old
+IRIX 6.5.x releases, @math{x < 19}.  The problem cannot be autodetected
+and in order to build GCC for such targets you need to configure with
+@option{--disable-wchar_t}.
+See @uref{http://freeware.sgi.com/} for more
+information about using GCC on IRIX platforms.
+@html
+<hr />
+@end html
+@heading @anchor{powerpc-x-x}powerpc-*-*
+You can specify a default version for the @option{-mcpu=@var{cpu_type}}
+switch by using the configure option @option{--with-cpu-@var{cpu_type}}.
+You will need
+@uref{ftp://ftp.kernel.org/pub/linux/devel/binutils,,binutils 2.15}
+or newer for a working GCC@.
+@html
+<hr />
+@end html
+@heading @anchor{powerpc-x-darwin}powerpc-*-darwin*
+PowerPC running Darwin (Mac OS X kernel).
+Pre-installed versions of Mac OS X may not include any developer tools,
+meaning that you will not be able to build GCC from source.  Tool
+binaries are available at
+@uref{http://developer.apple.com/darwin/projects/compiler/} (free
+registration required).
+This version of GCC requires at least cctools-590.36.  The
+cctools-590.36 package referenced from
+@uref{http://gcc.gnu.org/ml/gcc/2006-03/msg00507.html} will not work
+on systems older than 10.3.9 (aka darwin7.9.0).
+@html
+<hr />
+@end html
+@heading @anchor{powerpc-x-elf}powerpc-*-elf
+PowerPC system in big endian mode, running System V.4.
+@html
+<hr />
+@end html
+@heading @anchor{powerpc-x-linux-gnu}powerpc*-*-linux-gnu*
+PowerPC system in big endian mode running Linux.
+@html
+<hr />
+@end html
+@heading @anchor{powerpc-x-netbsd}powerpc-*-netbsd*
+PowerPC system in big endian mode running NetBSD@.
+@html
+<hr />
+@end html
+@heading @anchor{powerpc-x-eabisim}powerpc-*-eabisim
+Embedded PowerPC system in big endian mode for use in running under the
+PSIM simulator.
+@html
+<hr />
+@end html
+@heading @anchor{powerpc-x-eabi}powerpc-*-eabi
+Embedded PowerPC system in big endian mode.
+@html
+<hr />
+@end html
+@heading @anchor{powerpcle-x-elf}powerpcle-*-elf
+PowerPC system in little endian mode, running System V.4.
+@html
+<hr />
+@end html
+@heading @anchor{powerpcle-x-eabisim}powerpcle-*-eabisim
+Embedded PowerPC system in little endian mode for use in running under
+the PSIM simulator.
+@html
+<hr />
+@end html
+@heading @anchor{powerpcle-x-eabi}powerpcle-*-eabi
+Embedded PowerPC system in little endian mode.
+@html
+<hr />
+@end html
+@heading @anchor{s390-x-linux}s390-*-linux*
+S/390 system running GNU/Linux for S/390@.
+@html
+<hr />
+@end html
+@heading @anchor{s390x-x-linux}s390x-*-linux*
+zSeries system (64-bit) running GNU/Linux for zSeries@.
+@html
+<hr />
+@end html
+@heading @anchor{s390x-ibm-tpf}s390x-ibm-tpf*
+zSeries system (64-bit) running TPF@.  This platform is
+supported as cross-compilation target only.
+@html
+<hr />
+@end html
+@c Please use Solaris 2 to refer to all release of Solaris, starting
+@c with 2.0 until 2.6, 7, 8, etc.  Solaris 1 was a marketing name for
+@c SunOS 4 releases which we don't use to avoid confusion.  Solaris
+@c alone is too unspecific and must be avoided.
+@heading @anchor{x-x-solaris2}*-*-solaris2*
+Sun does not ship a C compiler with Solaris 2.  To bootstrap and install
+GCC you first have to install a pre-built compiler, see the
+@uref{binaries.html,,binaries page} for details.
+The Solaris 2 @command{/bin/sh} will often fail to configure
+@file{libstdc++-v3}, @file{boehm-gc} or @file{libjava}.  We therefore
+recommend using the following initial sequence of commands
+@smallexample
+% CONFIG_SHELL=/bin/ksh
+% export CONFIG_SHELL
+@end smallexample
+and proceed as described in @uref{configure.html,,the configure instructions}.
+In addition we strongly recommend specifying an absolute path to invoke
+@var{srcdir}/configure.
+Solaris 2 comes with a number of optional OS packages.  Some of these
+are needed to use GCC fully, namely @code{SUNWarc},
+@code{SUNWbtool}, @code{SUNWesu}, @code{SUNWhea}, @code{SUNWlibm},
+@code{SUNWsprot}, and @code{SUNWtoo}.  If you did not install all
+optional packages when installing Solaris 2, you will need to verify that
+the packages that GCC needs are installed.
+To check whether an optional package is installed, use
+the @command{pkginfo} command.  To add an optional package, use the
+@command{pkgadd} command.  For further details, see the Solaris 2
+documentation.
+Trying to use the linker and other tools in
+@file{/usr/ucb} to install GCC has been observed to cause trouble.
+For example, the linker may hang indefinitely.  The fix is to remove
+@file{/usr/ucb} from your @env{PATH}.
+The build process works more smoothly with the legacy Sun tools so, if you
+have @file{/usr/xpg4/bin} in your @env{PATH}, we recommend that you place
+@file{/usr/bin} before @file{/usr/xpg4/bin} for the duration of the build.
+We recommend the use of GNU binutils 2.14 or later, or the vendor tools
+(Sun @command{as}, Sun @command{ld}).  Note that your mileage may vary
+if you use a combination of the GNU tools and the Sun tools: while the
+combination GNU @command{as} + Sun @command{ld} should reasonably work,
+the reverse combination Sun @command{as} + GNU @command{ld} is known to
+cause memory corruption at runtime in some cases for C++ programs.
+The stock GNU binutils 2.15 release is broken on this platform because of a
+single bug.  It has been fixed on the 2.15 branch in the CVS repository.
+You can obtain a working version by checking out the binutils-2_15-branch
+from the CVS repository or applying the patch
+@uref{http://sourceware.org/ml/binutils-cvs/2004-09/msg00036.html} to the
+release.
+We recommend the use of GNU binutils 2.16 or later in conjunction with GCC
+4.x, or the vendor tools (Sun @command{as}, Sun @command{ld}).  However,
+for Solaris 10 and above, an additional patch is required in order for the
+GNU linker to be able to cope with a new flavor of shared libraries.  You
+can obtain a working version by checking out the binutils-2_16-branch from
+the CVS repository or applying the patch
+@uref{http://sourceware.org/ml/binutils-cvs/2005-07/msg00122.html} to the
+release.
+Sun bug 4296832 turns up when compiling X11 headers with GCC 2.95 or
+newer: @command{g++} will complain that types are missing.  These headers
+assume that omitting the type means @code{int}; this assumption worked for
+C89 but is wrong for C++, and is now wrong for C99 also.
+@command{g++} accepts such (invalid) constructs with the option
+@option{-fpermissive}; it will assume that any missing type is @code{int}
+(as defined by C89).
+There are patches for Solaris 7 (108376-21 or newer for SPARC,
+108377-20 for Intel), and Solaris 8 (108652-24 or newer for SPARC,
+108653-22 for Intel) that fix this bug.
+Sun bug 4927647 sometimes causes random spurious testsuite failures
+related to missing diagnostic output.  This bug doesn't affect GCC
+itself, rather it is a kernel bug triggered by the @command{expect}
+program which is used only by the GCC testsuite driver.  When the bug
+causes the @command{expect} program to miss anticipated output, extra
+testsuite failures appear.
+There are patches for Solaris 8 (117350-12 or newer for SPARC,
+117351-12 or newer for Intel) and Solaris 9 (117171-11 or newer for
+SPARC, 117172-11 or newer for Intel) that address this problem.
+@html
+<hr />
+@end html
+@heading @anchor{sparc-sun-solaris2}sparc-sun-solaris2*
+When GCC is configured to use binutils 2.14 or later the binaries
+produced are smaller than the ones produced using Sun's native tools;
+this difference is quite significant for binaries containing debugging
+information.
+Starting with Solaris 7, the operating system is capable of executing
+64-bit SPARC V9 binaries.  GCC 3.1 and later properly supports
+this; the @option{-m64} option enables 64-bit code generation.
+However, if all you want is code tuned for the UltraSPARC CPU, you
+should try the @option{-mtune=ultrasparc} option instead, which produces
+code that, unlike full 64-bit code, can still run on non-UltraSPARC
+machines.
+When configuring on a Solaris 7 or later system that is running a kernel
+that supports only 32-bit binaries, one must configure with
+@option{--disable-multilib}, since we will not be able to build the
+64-bit target libraries.
+GCC 3.3 and GCC 3.4 trigger code generation bugs in earlier versions of
+the GNU compiler (especially GCC 3.0.x versions), which lead to the
+miscompilation of the stage1 compiler and the subsequent failure of the
+bootstrap process.  A workaround is to use GCC 3.2.3 as an intermediary
+stage, i.e.@: to bootstrap that compiler with the base compiler and then
+use it to bootstrap the final compiler.
+GCC 3.4 triggers a code generation bug in versions 5.4 (Sun ONE Studio 7)
+and 5.5 (Sun ONE Studio 8) of the Sun compiler, which causes a bootstrap
+failure in form of a miscompilation of the stage1 compiler by the Sun
+compiler.  This is Sun bug 4974440.  This is fixed with patch 112760-07.
+GCC 3.4 changed the default debugging format from STABS to DWARF-2 for
+32-bit code on Solaris 7 and later.  If you use the Sun assembler, this
+change apparently runs afoul of Sun bug 4910101 (which is referenced as
+a x86-only problem by Sun, probably because they do not use DWARF-2).
+A symptom of the problem is that you cannot compile C++ programs like
+@command{groff} 1.19.1 without getting messages similar to the following:
+@smallexample
+ld: warning: relocation error: R_SPARC_UA32: @dots{}
+external symbolic relocation against non-allocatable section
+.debug_info cannot be processed at runtime: relocation ignored.
+@end smallexample
+To work around this problem, compile with @option{-gstabs+} instead of
+plain @option{-g}.
+When configuring the GNU Multiple Precision Library (GMP) or the MPFR
+library on a Solaris 7 or later system, the canonical target triplet
+must be specified as the @command{build} parameter on the configure
+line.  This triplet can be obtained by invoking ./config.guess in
+the toplevel source directory of GCC (and not that of GMP or MPFR).
+For example on a Solaris 7 system:
+@smallexample
+% ./configure --build=sparc-sun-solaris2.7 --prefix=xxx
+@end smallexample
+@html
+<hr />
+@end html
+@heading @anchor{sparc-sun-solaris27}sparc-sun-solaris2.7
+Sun patch 107058-01 (1999-01-13) for Solaris 7/SPARC triggers a bug in
+the dynamic linker.  This problem (Sun bug 4210064) affects GCC 2.8
+and later, including all EGCS releases.  Sun formerly recommended
+107058-01 for all Solaris 7 users, but around 1999-09-01 it started to
+recommend it only for people who use Sun's compilers.
+Here are some workarounds to this problem:
+@itemize @bullet
+@item
+Do not install Sun patch 107058-01 until after Sun releases a
+complete patch for bug 4210064.  This is the simplest course to take,
+unless you must also use Sun's C compiler.  Unfortunately 107058-01
+is preinstalled on some new Solaris 7-based hosts, so you may have to
+back it out.
+@item
+Copy the original, unpatched Solaris 7
+@command{/usr/ccs/bin/as} into
+@command{/usr/local/libexec/gcc/sparc-sun-solaris2.7/3.4/as},
+adjusting the latter name to fit your local conventions and software
+version numbers.
+@item
+Install Sun patch 106950-03 (1999-05-25) or later.  Nobody with
+both 107058-01 and 106950-03 installed has reported the bug with GCC
+and Sun's dynamic linker.  This last course of action is riskiest,
+for two reasons.  First, you must install 106950 on all hosts that
+run code generated by GCC; it doesn't suffice to install it only on
+the hosts that run GCC itself.  Second, Sun says that 106950-03 is
+only a partial fix for bug 4210064, but Sun doesn't know whether the
+partial fix is adequate for GCC@.  Revision -08 or later should fix
+the bug.  The current (as of 2004-05-23) revision is -24, and is included in
+the Solaris 7 Recommended Patch Cluster.
+@end itemize
+GCC 3.3 triggers a bug in version 5.0 Alpha 03/27/98 of the Sun assembler,
+which causes a bootstrap failure when linking the 64-bit shared version of
+libgcc.  A typical error message is:
+@smallexample
+ld: fatal: relocation error: R_SPARC_32: file libgcc/sparcv9/_muldi3.o:
+symbol <unknown>:  offset 0xffffffff7ec133e7 is non-aligned.
+@end smallexample
+This bug has been fixed in the final 5.0 version of the assembler.
+A similar problem was reported for version Sun WorkShop 6 99/08/18 of the
+Sun assembler, which causes a bootstrap failure with GCC 4.0.0:
+@smallexample
+ld: fatal: relocation error: R_SPARC_DISP32:
+file .libs/libstdc++.lax/libsupc++convenience.a/vterminate.o:
+symbol <unknown>: offset 0xfccd33ad is non-aligned
+@end smallexample
+This bug has been fixed in more recent revisions of the assembler.
+@html
+<hr />
+@end html
+@heading @anchor{sparc-x-linux}sparc-*-linux*
+GCC versions 3.0 and higher require binutils 2.11.2 and glibc 2.2.4
+or newer on this platform.  All earlier binutils and glibc
+releases mishandled unaligned relocations on @code{sparc-*-*} targets.
+@html
+<hr />
+@end html
+@heading @anchor{sparc64-x-solaris2}sparc64-*-solaris2*
+When configuring the GNU Multiple Precision Library (GMP) or the
+MPFR library, the canonical target triplet must be specified as
+the @command{build} parameter on the configure line.  For example
+on a Solaris 7 system:
+@smallexample
+% ./configure --build=sparc64-sun-solaris2.7 --prefix=xxx
+@end smallexample
+The following compiler flags must be specified in the configure
+step in order to bootstrap this target with the Sun compiler:
+@smallexample
+% CC="cc -xarch=v9 -xildoff" @var{srcdir}/configure [@var{options}] [@var{target}]
+@end smallexample
+@option{-xarch=v9} specifies the SPARC-V9 architecture to the Sun toolchain
+and @option{-xildoff} turns off the incremental linker.
+@html
+<hr />
+@end html
+@heading @anchor{sparcv9-x-solaris2}sparcv9-*-solaris2*
+This is a synonym for sparc64-*-solaris2*.
+@html
+<hr />
+@end html
+@heading @anchor{x-x-vxworks}*-*-vxworks*
+Support for VxWorks is in flux.  At present GCC supports @emph{only} the
+very recent VxWorks 5.5 (aka Tornado 2.2) release, and only on PowerPC@.
+We welcome patches for other architectures supported by VxWorks 5.5.
+Support for VxWorks AE would also be welcome; we believe this is merely
+a matter of writing an appropriate ``configlette'' (see below).  We are
+not interested in supporting older, a.out or COFF-based, versions of
+VxWorks in GCC 3.
+VxWorks comes with an older version of GCC installed in
+@file{@var{$WIND_BASE}/host}; we recommend you do not overwrite it.
+Choose an installation @var{prefix} entirely outside @var{$WIND_BASE}.
+Before running @command{configure}, create the directories @file{@var{prefix}}
+and @file{@var{prefix}/bin}.  Link or copy the appropriate assembler,
+linker, etc.@: into @file{@var{prefix}/bin}, and set your @var{PATH} to
+include that directory while running both @command{configure} and
+@command{make}.
+You must give @command{configure} the
+@option{--with-headers=@var{$WIND_BASE}/target/h} switch so that it can
+find the VxWorks system headers.  Since VxWorks is a cross compilation
+target only, you must also specify @option{--target=@var{target}}.
+@command{configure} will attempt to create the directory
+@file{@var{prefix}/@var{target}/sys-include} and copy files into it;
+make sure the user running @command{configure} has sufficient privilege
+to do so.
+GCC's exception handling runtime requires a special ``configlette''
+module, @file{contrib/gthr_supp_vxw_5x.c}.  Follow the instructions in
+that file to add the module to your kernel build.  (Future versions of
+VxWorks will incorporate this module.)
+@html
+<hr />
+@end html
+@heading @anchor{x86-64-x-x}x86_64-*-*, amd64-*-*
+GCC supports the x86-64 architecture implemented by the AMD64 processor
+(amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD@.
+On GNU/Linux the default is a bi-arch compiler which is able to generate
+both 64-bit x86-64 and 32-bit x86 code (via the @option{-m32} switch).
+@html
+<hr />
+@end html
+@heading @anchor{xtensa-x-elf}xtensa*-*-elf
+This target is intended for embedded Xtensa systems using the
+@samp{newlib} C library.  It uses ELF but does not support shared
+objects.  Designed-defined instructions specified via the
+Tensilica Instruction Extension (TIE) language are only supported
+through inline assembly.
+The Xtensa configuration information must be specified prior to
+building GCC@.  The @file{include/xtensa-config.h} header
+file contains the configuration information.  If you created your
+own Xtensa configuration with the Xtensa Processor Generator, the
+downloaded files include a customized copy of this header file,
+which you can use to replace the default header file.
+@html
+<hr />
+@end html
+@heading @anchor{xtensa-x-linux}xtensa*-*-linux*
+This target is for Xtensa systems running GNU/Linux.  It supports ELF
+shared objects and the GNU C library (glibc).  It also generates
+position-independent code (PIC) regardless of whether the
+@option{-fpic} or @option{-fPIC} options are used.  In other
+respects, this target is the same as the
+@uref{#xtensa*-*-elf,,@samp{xtensa*-*-elf}} target.
+@html
+<hr />
+@end html
+@heading @anchor{windows}Microsoft Windows
+@subheading Intel 16-bit versions
+The 16-bit versions of Microsoft Windows, such as Windows 3.1, are not
+supported.
+However, the 32-bit port has limited support for Microsoft
+Windows 3.11 in the Win32s environment, as a target only.  See below.
+@subheading Intel 32-bit versions
+The 32-bit versions of Windows, including Windows 95, Windows NT, Windows
+XP, and Windows Vista, are supported by several different target
+platforms.  These targets differ in which Windows subsystem they target
+and which C libraries are used.
+@itemize
+@item Cygwin @uref{#x-x-cygwin,,*-*-cygwin}: Cygwin provides a user-space
+Linux API emulation layer in the Win32 subsystem.
+@item Interix @uref{#x-x-interix,,*-*-interix}: The Interix subsystem
+provides native support for POSIX.
+@item MinGW @uref{#x-x-mingw,,*-*-mingw}: MinGW is a native GCC port for
+the Win32 subsystem that provides a subset of POSIX.
+@item MKS i386-pc-mks: NuTCracker from MKS.  See
+@uref{http://www.mkssoftware.com/} for more information.
+@end itemize
+@subheading Intel 64-bit versions
+GCC contains support for x86-64 using the mingw-w64
+runtime library, available from @uref{http://mingw-w64.sourceforge.net/}.
+This library should be used with the target triple x86_64-pc-mingw32.
+Presently Windows for Itanium is not supported.
+@subheading Windows CE
+Windows CE is supported as a target only on ARM (arm-wince-pe), Hitachi
+SuperH (sh-wince-pe), and MIPS (mips-wince-pe).
+@subheading Other Windows Platforms
+GCC no longer supports Windows NT on the Alpha or PowerPC.
+GCC no longer supports the Windows POSIX subsystem.  However, it does
+support the Interix subsystem.  See above.
+Old target names including *-*-winnt and *-*-windowsnt are no longer used.
+PW32 (i386-pc-pw32) support was never completed, and the project seems to
+be inactive.  See @uref{http://pw32.sourceforge.net/} for more information.
+UWIN support has been removed due to a lack of maintenance.
+@html
+<hr />
+@end html
+@heading @anchor{x-x-cygwin}*-*-cygwin
+Ports of GCC are included with the
+@uref{http://www.cygwin.com/,,Cygwin environment}.
+GCC will build under Cygwin without modification; it does not build
+with Microsoft's C++ compiler and there are no plans to make it do so.
+Cygwin can be compiled with i?86-pc-cygwin.
+@html
+<hr />
+@end html
+@heading @anchor{x-x-interix}*-*-interix
+The Interix target is used by OpenNT, Interix, Services For UNIX (SFU),
+and Subsystem for UNIX-based Applications (SUA).  Applications compiled
+with this target run in the Interix subsystem, which is separate from
+the Win32 subsystem.  This target was last known to work in GCC 3.3.
+For more information, see @uref{http://www.interix.com/}.
+@html
+<hr />
+@end html
+@heading @anchor{x-x-mingw32}*-*-mingw32
+GCC will build with and support only MinGW runtime 3.12 and later.
+Earlier versions of headers are incompatible with the new default semantics
+of @code{extern inline} in @code{-std=c99} and @code{-std=gnu99} modes.
+@html
+<hr />
+@end html
+@heading @anchor{os2}OS/2
+GCC does not currently support OS/2.  However, Andrew Zabolotny has been
+working on a generic OS/2 port with pgcc.  The current code can be found
+at @uref{http://www.goof.com/pcg/os2/,,http://www.goof.com/pcg/os2/}.
+@html
+<hr />
+@end html
+@heading @anchor{older}Older systems
+GCC contains support files for many older (1980s and early
+1990s) Unix variants.  For the most part, support for these systems
+has not been deliberately removed, but it has not been maintained for
+several years and may suffer from bitrot.
+Starting with GCC 3.1, each release has a list of ``obsoleted'' systems.
+Support for these systems is still present in that release, but
+@command{configure} will fail unless the @option{--enable-obsolete}
+option is given.  Unless a maintainer steps forward, support for these
+systems will be removed from the next release of GCC@.
+Support for old systems as hosts for GCC can cause problems if the
+workarounds for compiler, library and operating system bugs affect the
+cleanliness or maintainability of the rest of GCC@.  In some cases, to
+bring GCC up on such a system, if still possible with current GCC, may
+require first installing an old version of GCC which did work on that
+system, and using it to compile a more recent GCC, to avoid bugs in the
+vendor compiler.  Old releases of GCC 1 and GCC 2 are available in the
+@file{old-releases} directory on the @uref{../mirrors.html,,GCC mirror
+sites}.  Header bugs may generally be avoided using
+@command{fixincludes}, but bugs or deficiencies in libraries and the
+operating system may still cause problems.
+Support for older systems as targets for cross-compilation is less
+problematic than support for them as hosts for GCC; if an enthusiast
+wishes to make such a target work again (including resurrecting any of
+the targets that never worked with GCC 2, starting from the last
+version before they were removed), patches
+@uref{../contribute.html,,following the usual requirements} would be
+likely to be accepted, since they should not affect the support for more
+modern targets.
+For some systems, old versions of GNU binutils may also be useful,
+and are available from @file{pub/binutils/old-releases} on
+@uref{http://sourceware.org/mirrors.html,,sourceware.org mirror sites}.
+Some of the information on specific systems above relates to
+such older systems, but much of the information
+about GCC on such systems (which may no longer be applicable to
+current GCC) is to be found in the GCC texinfo manual.
+@html
+<hr />
+@end html
+@heading @anchor{elf}all ELF targets (SVR4, Solaris 2, etc.)
+C++ support is significantly better on ELF targets if you use the
+@uref{./configure.html#with-gnu-ld,,GNU linker}; duplicate copies of
+inlines, vtables and template instantiations will be discarded
+automatically.
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+@c ***Old documentation******************************************************
+@ifset oldhtml
+@include install-old.texi
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+@c ***GFDL********************************************************************
+@ifset gfdlhtml
+@include fdl.texi
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+@c ***************************************************************************
+@c Part 6 The End of the Document
+@ifinfo
+@comment node-name,     next,          previous, up
+@node    Concept Index, , GNU Free Documentation License, Top
+@end ifinfo
+@ifinfo
+@unnumbered Concept Index
+@printindex cp
+@contents
+@end ifinfo
+@bye

Mercurial > hg > CbC > CbC_gcc

comparison gcc/doc/install.texi @ 0:a06113de4d67