699 lines
36 KiB
HTML
699 lines
36 KiB
HTML
<html lang="en">
|
|
<head>
|
|
<title>Installing GCC: Configuration</title>
|
|
<meta http-equiv="Content-Type" content="text/html">
|
|
<meta name="description" content="Installing GCC: Configuration">
|
|
<meta name="generator" content="makeinfo 4.6">
|
|
<!--
|
|
Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|
|
1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
|
|
<br><p>
|
|
<p>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 "<a href="./gfdl.html">GNU Free Documentation License</a>".
|
|
|
|
<p>(a) The FSF's Front-Cover Text is:
|
|
|
|
<p>A GNU Manual
|
|
|
|
<p>(b) The FSF's Back-Cover Text is:
|
|
|
|
<p>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.-->
|
|
<meta http-equiv="Content-Style-Type" content="text/css">
|
|
<style type="text/css"><!--
|
|
pre.display { font-family:inherit }
|
|
pre.format { font-family:inherit }
|
|
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
|
pre.smallformat { font-family:inherit; font-size:smaller }
|
|
pre.smallexample { font-size:smaller }
|
|
pre.smalllisp { font-size:smaller }
|
|
--></style>
|
|
</head>
|
|
<body>
|
|
<h1 class="settitle">Installing GCC: Configuration</h1>
|
|
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.
|
|
|
|
<p>We use <var>srcdir</var> to refer to the toplevel source directory for
|
|
GCC; we use <var>objdir</var> to refer to the toplevel build/object directory.
|
|
|
|
<p>If you obtained the sources via CVS, <var>srcdir</var> must refer to the top
|
|
<code>gcc</code> directory, the one where the <code>MAINTAINERS</code> can be found,
|
|
and not its <code>gcc</code> subdirectory, otherwise the build will fail.
|
|
|
|
<p>If either <var>srcdir</var> or <var>objdir</var> is located on an automounted NFS
|
|
file system, the shell's built-in <code>pwd</code> command will return
|
|
temporary pathnames. Using these can lead to various sorts of build
|
|
problems. To avoid this issue, set the <code>PWDCMD</code> environment
|
|
variable to an automounter-aware <code>pwd</code> command, e.g.,
|
|
<code>pawd</code> or <code>amq -w</code>, during the configuration and build
|
|
phases.
|
|
|
|
<p>First, we <strong>highly</strong> recommend that GCC be built into a
|
|
separate directory than the sources which does <strong>not</strong> reside
|
|
within the source tree. This is how we generally build GCC; building
|
|
where <var>srcdir</var> == <var>objdir</var> should still work, but doesn't
|
|
get extensive testing; building where <var>objdir</var> is a subdirectory
|
|
of <var>srcdir</var> is unsupported.
|
|
|
|
<p>If you have previously built GCC in the same directory for a
|
|
different target machine, do <code>make distclean</code> to delete all files
|
|
that might be invalid. One of the files this deletes is <code>Makefile</code>;
|
|
if <code>make distclean</code> complains that <code>Makefile</code> 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</var>, you should
|
|
simply use a different <var>objdir</var> for each target.
|
|
|
|
<p>Second, when configuring a native system, either <code>cc</code> or
|
|
<code>gcc</code> must be in your path or you must set <code>CC</code> in
|
|
your environment before running configure. Otherwise the configuration
|
|
scripts may fail.
|
|
|
|
<p>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
|
|
<a href="specific.html">host/target specific installation notes</a>.
|
|
|
|
<p>To configure GCC:
|
|
|
|
<pre class="example"> % mkdir <var>objdir</var>
|
|
% cd <var>objdir</var>
|
|
% <var>srcdir</var>/configure [<var>options</var>] [<var>target</var>]
|
|
</pre>
|
|
|
|
<h3 class="heading"><a name="TOC0"></a>Target specification</h3>
|
|
|
|
<ul>
|
|
<li>GCC has code to correctly determine the correct value for <var>target</var>
|
|
for nearly all native systems. Therefore, we highly recommend you not
|
|
provide a configure target when configuring a native compiler.
|
|
|
|
<li><var>target</var> must be specified as <code>--target=</code><var>target</var><code></code>
|
|
when configuring a cross compiler; examples of valid targets would be
|
|
i960-rtems, m68k-coff, sh-elf, etc.
|
|
|
|
<li>Specifying just <var>target</var> instead of <code>--target=</code><var>target</var><code></code>
|
|
implies that the host defaults to <var>target</var>.
|
|
</ul>
|
|
|
|
<h3 class="heading"><a name="TOC1"></a>Options specification</h3>
|
|
|
|
<p>Use <var>options</var> to override several configure time options for
|
|
GCC. A list of supported <var>options</var> follows; <code>configure
|
|
--help</code> may list other options, but those not listed below may not
|
|
work and should not normally be used.
|
|
|
|
<dl>
|
|
<dt><code>--prefix=</code><var>dirname</var><code></code>
|
|
<dd>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
|
|
<code>/usr/local</code>.
|
|
|
|
<p>We <strong>highly</strong> recommend against <var>dirname</var> being the same or a
|
|
subdirectory of <var>objdir</var> or vice versa. If specifying a directory
|
|
beneath a user's home directory tree, some shells will not expand
|
|
<var>dirname</var> correctly if it contains the <code>~</code> metacharacter; use
|
|
<code>$HOME</code> instead.
|
|
|
|
<p>These additional options control where certain parts of the distribution
|
|
are installed. Normally you should not need to use these options.
|
|
<dl>
|
|
<dt><code>--exec-prefix=</code><var>dirname</var><code></code>
|
|
<dd>Specify the toplevel installation directory for architecture-dependent
|
|
files. The default is <code></code><var>prefix</var><code></code>.
|
|
|
|
<br><dt><code>--bindir=</code><var>dirname</var><code></code>
|
|
<dd>Specify the installation directory for the executables called by users
|
|
(such as <code>gcc</code> and <code>g++</code>). The default is
|
|
<code></code><var>exec-prefix</var><code>/bin</code>.
|
|
|
|
<br><dt><code>--libdir=</code><var>dirname</var><code></code>
|
|
<dd>Specify the installation directory for object code libraries and
|
|
internal parts of GCC. The default is <code></code><var>exec-prefix</var><code>/lib</code>.
|
|
|
|
<br><dt><code>--with-slibdir=</code><var>dirname</var><code></code>
|
|
<dd>Specify the installation directory for the shared libgcc library. The
|
|
default is <code></code><var>libdir</var><code></code>.
|
|
|
|
<br><dt><code>--infodir=</code><var>dirname</var><code></code>
|
|
<dd>Specify the installation directory for documentation in info format.
|
|
The default is <code></code><var>prefix</var><code>/info</code>.
|
|
|
|
<br><dt><code>--datadir=</code><var>dirname</var><code></code>
|
|
<dd>Specify the installation directory for some architecture-independent
|
|
data files referenced by GCC. The default is <code></code><var>prefix</var><code>/share</code>.
|
|
|
|
<br><dt><code>--mandir=</code><var>dirname</var><code></code>
|
|
<dd>Specify the installation directory for manual pages. The default is
|
|
<code></code><var>prefix</var><code>/man</code>. (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.)
|
|
|
|
<br><dt><code>--with-gxx-include-dir=</code><var>dirname</var><code></code>
|
|
<dd>Specify
|
|
the installation directory for G++ header files. The default is
|
|
<code></code><var>prefix</var><code>/include/g++-v3</code>.
|
|
|
|
</dl>
|
|
|
|
<br><dt><code>--program-prefix=</code><var>prefix</var><code></code>
|
|
<dd>GCC supports some transformations of the names of its programs when
|
|
installing them. This option prepends <var>prefix</var> to the names of
|
|
programs to install in <var>bindir</var> (see above). For example, specifying
|
|
<code>--program-prefix=foo-</code> would result in <code>gcc</code>
|
|
being installed as <code>/usr/local/bin/foo-gcc</code>.
|
|
|
|
<br><dt><code>--program-suffix=</code><var>suffix</var><code></code>
|
|
<dd>Appends <var>suffix</var> to the names of programs to install in <var>bindir</var>
|
|
(see above). For example, specifying <code>--program-suffix=-3.1</code>
|
|
would result in <code>gcc</code> being installed as
|
|
<code>/usr/local/bin/gcc-3.1</code>.
|
|
|
|
<br><dt><code>--program-transform-name=</code><var>pattern</var><code></code>
|
|
<dd>Applies the <code>sed</code> script <var>pattern</var> to be applied to the names
|
|
of programs to install in <var>bindir</var> (see above). <var>pattern</var> has to
|
|
consist of one or more basic <code>sed</code> editing commands, separated by
|
|
semicolons. For example, if you want the <code>gcc</code> program name to be
|
|
transformed to the installed program <code>/usr/local/bin/myowngcc</code> and
|
|
the <code>g++</code> program name to be transformed to
|
|
<code>/usr/local/bin/gspecial++</code> without changing other program names,
|
|
you could use the pattern
|
|
<code>--program-transform-name='s/^gcc$/myowngcc/; s/^g++$/gspecial++/'</code>
|
|
to achieve this effect.
|
|
|
|
<p>All three options can be combined and used together, resulting in more
|
|
complex conversion patterns. As a basic rule, <var>prefix</var> (and
|
|
<var>suffix</var>) are prepended (appended) before further transformations
|
|
can happen with a special transformation script <var>pattern</var>.
|
|
|
|
<p>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.
|
|
|
|
<p>For native builds, some of the installed programs are also installed
|
|
with the target alias in front of their name, as in
|
|
<code>i686-pc-linux-gnu-gcc</code>. All of the above transformations happen
|
|
before the target alias is prepended to the name - so, specifying
|
|
<code>--program-prefix=foo-</code> and <code>program-suffix=-3.1</code>, the
|
|
resulting binary would be installed as
|
|
<code>/usr/local/bin/i686-pc-linux-gnu-foo-gcc-3.1</code>.
|
|
|
|
<p>As a last shortcoming, none of the installed Ada programs are
|
|
transformed yet, which will be fixed in some time.
|
|
|
|
<br><dt><code>--with-local-prefix=</code><var>dirname</var><code></code>
|
|
<dd>Specify the
|
|
installation directory for local include files. The default is
|
|
<code>/usr/local</code>. Specify this option if you want the compiler to
|
|
search directory <code></code><var>dirname</var><code>/include</code> for locally installed
|
|
header files <em>instead</em> of <code>/usr/local/include</code>.
|
|
|
|
<p>You should specify <code>--with-local-prefix</code> <strong>only</strong> if your
|
|
site has a different convention (not <code>/usr/local</code>) for where to put
|
|
site-specific files.
|
|
|
|
<p>The default value for <code>--with-local-prefix</code> is <code>/usr/local</code>
|
|
regardless of the value of <code>--prefix</code>. Specifying
|
|
<code>--prefix</code> has no effect on which directory GCC searches for
|
|
local header files. This may seem counterintuitive, but actually it is
|
|
logical.
|
|
|
|
<p>The purpose of <code>--prefix</code> is to specify where to <em>install
|
|
GCC</em>. The local header files in <code>/usr/local/include</code>--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 <code>--prefix</code> value.)
|
|
|
|
<p>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.
|
|
|
|
<p>Some autoconf macros add <code>-I </code><var>directory</var><code></code> options to the
|
|
compiler command line, to ensure that directories containing installed
|
|
packages' headers are searched. When <var>directory</var> 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.
|
|
|
|
<p>GCC automatically searches for ordinary libraries using
|
|
<code>GCC_EXEC_PREFIX</code>. 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 <code>/usr</code>.
|
|
|
|
<p>Sites that need to install multiple versions of GCC may not want to
|
|
use the above simple configuration. It is possible to use the
|
|
<code>--program-prefix</code>, <code>--program-suffix</code> and
|
|
<code>--program-transform-name</code> options to install multiple versions
|
|
into a single directory, but it may be simpler to use different prefixes
|
|
and the <code>--with-local-prefix</code> 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 <code>LIBRARY_PATH</code>).
|
|
|
|
<p>The same value can be used for both <code>--with-local-prefix</code> and
|
|
<code>--prefix</code> provided it is not <code>/usr</code>. This can be used
|
|
to avoid the default search of <code>/usr/local/include</code>.
|
|
|
|
<p><strong>Do not</strong> specify <code>/usr</code> as the <code>--with-local-prefix</code>!
|
|
The directory you use for <code>--with-local-prefix</code> <strong>must not</strong>
|
|
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 <code>fixincludes</code> script.
|
|
|
|
<p>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.
|
|
|
|
<br><dt><code>--enable-shared[=</code><var>package</var><code>[,...]]</code>
|
|
<dd>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,
|
|
except for <code>libobjc</code> which is built as a static library only by
|
|
default.
|
|
|
|
<p>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
|
|
<code>libgcc</code> (also known as <code>gcc</code>), <code>libstdc++</code> (not
|
|
<code>libstdc++-v3</code>), <code>libffi</code>, <code>zlib</code>, <code>boehm-gc</code> and
|
|
<code>libjava</code>. Note that <code>libobjc</code> does not recognize itself by
|
|
any name, so, if you list package names in <code>--enable-shared</code>,
|
|
you will only get static Objective-C libraries. <code>libf2c</code> and
|
|
<code>libiberty</code> do not support shared libraries at all.
|
|
|
|
<p>Use <code>--disable-shared</code> to build only static libraries. Note that
|
|
<code>--disable-shared</code> does not accept a list of package names as
|
|
argument, only <code>--enable-shared</code> does.
|
|
|
|
<br><dt><code><a name="with-gnu-as"></a>--with-gnu-as</code>
|
|
<dd>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 <code>--with-gnu-as</code>.) If you have more than one
|
|
assembler installed on your system, you may want to use this option in
|
|
connection with <code>--with-as=</code><var>pathname</var><code></code>.
|
|
|
|
<p>The following systems are the only ones where it makes a difference
|
|
whether you use the GNU assembler. On any other system,
|
|
<code>--with-gnu-as</code> has no effect.
|
|
|
|
<ul>
|
|
<li><code>hppa1.0-</code><var>any</var><code>-</code><var>any</var><code></code>
|
|
<li><code>hppa1.1-</code><var>any</var><code>-</code><var>any</var><code></code>
|
|
<li><code>i386-</code><var>any</var><code>-sysv</code>
|
|
<li><code>m68k-bull-sysv</code>
|
|
<li><code>m68k-hp-hpux</code>
|
|
<li><code>m68000-hp-hpux</code>
|
|
<li><code>m68000-att-sysv</code>
|
|
<li><code></code><var>any</var><code>-lynx-lynxos</code>
|
|
<li><code>mips-</code><var>any</var><code></code>
|
|
<li><code>sparc-sun-solaris2.</code><var>any</var><code></code>
|
|
<li><code>sparc64-</code><var>any</var><code>-solaris2.</code><var>any</var><code></code>
|
|
</ul>
|
|
|
|
<p>On the systems listed above (except for the HP-PA, the SPARC, for ISC on
|
|
the 386, and for <code>mips-sgi-irix5.*</code>), if you use the GNU assembler,
|
|
you should also use the GNU linker (and specify <code>--with-gnu-ld</code>).
|
|
|
|
<br><dt><code><a name="with-as"></a>--with-as=</code><var>pathname</var><code></code>
|
|
<dd>Specify that the
|
|
compiler should use the assembler pointed to by <var>pathname</var>, rather
|
|
than the one found by the standard rules to find an assembler, which
|
|
are:
|
|
<ul>
|
|
<li>Check the
|
|
<code></code><var>exec_prefix</var><code>/lib/gcc-lib/</code><var>target</var><code>/</code><var>version</var><code></code>
|
|
directory, where <var>exec_prefix</var> defaults to <var>prefix</var> which
|
|
defaults to <code>/usr/local</code> unless overridden by the
|
|
<code>--prefix=</code><var>pathname</var><code></code> switch described above. <var>target</var> is the
|
|
target system triple, such as <code>sparc-sun-solaris2.7</code>, and
|
|
<var>version</var> denotes the GCC version, such as 3.0.
|
|
<li>Check operating system specific directories (e.g. <code>/usr/ccs/bin</code> on
|
|
Sun Solaris 2).
|
|
</ul>
|
|
Note that these rules do not check for the value of <code>PATH</code>. You may
|
|
want to use <code>--with-as</code> 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.
|
|
|
|
<br><dt><code><a name="with-gnu-ld"></a>--with-gnu-ld</code>
|
|
<dd>Same as <a href="#with-gnu-as"><code>--with-gnu-as</code></a>
|
|
but for the linker.
|
|
|
|
<br><dt><code>--with-ld=</code><var>pathname</var><code></code>
|
|
<dd>Same as <a href="#with-as"><code>--with-as</code></a>
|
|
but for the linker.
|
|
|
|
<br><dt><code>--with-stabs</code>
|
|
<dd>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.
|
|
|
|
<p>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.
|
|
|
|
<p>Normally, GCC uses the ECOFF debugging format by default; if you
|
|
prefer BSD stabs, specify <code>--with-stabs</code> when you configure GCC.
|
|
|
|
<p>No matter which default you choose when you configure GCC, the user
|
|
can use the <code>-gcoff</code> and <code>-gstabs+</code> options to specify explicitly
|
|
the debug format for a particular compilation.
|
|
|
|
<p><code>--with-stabs</code> is meaningful on the ISC system on the 386, also, if
|
|
<code>--with-gas</code> 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.
|
|
|
|
<p><code>--with-stabs</code> 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.
|
|
|
|
<br><dt><code>--disable-multilib</code>
|
|
<dd>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.
|
|
|
|
<p>Some targets provide finer-grained control over which multilibs are built
|
|
(e.g., <code>--disable-softfloat</code>):
|
|
<dl>
|
|
<dt><code>arc-*-elf*</code>
|
|
<dd>biendian.
|
|
|
|
<br><dt><code>arm-*-*</code>
|
|
<dd>fpu, 26bit, underscore, interwork, biendian, nofmult.
|
|
|
|
<br><dt><code>m68*-*-*</code>
|
|
<dd>softfloat, m68881, m68000, m68020.
|
|
|
|
<br><dt><code>mips*-*-*</code>
|
|
<dd>single-float, biendian, softfloat.
|
|
|
|
<br><dt><code>powerpc*-*-*, rs6000*-*-*</code>
|
|
<dd>aix64, pthread, softfloat, powercpu, powerpccpu, powerpcos, biendian,
|
|
sysv, aix.
|
|
|
|
</dl>
|
|
|
|
<br><dt><code>--enable-threads</code>
|
|
<dd>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.
|
|
|
|
<p>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, <code>--enable-threads</code> is an
|
|
alias for <code>--enable-threads=single</code>.
|
|
|
|
<br><dt><code>--disable-threads</code>
|
|
<dd>Specify that threading support should be disabled for the system.
|
|
This is an alias for <code>--enable-threads=single</code>.
|
|
|
|
<br><dt><code>--enable-threads=</code><var>lib</var><code></code>
|
|
<dd>Specify that
|
|
<var>lib</var> 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</var> are:
|
|
|
|
<dl>
|
|
<dt><code>aix</code>
|
|
<dd>AIX thread support.
|
|
<br><dt><code>dce</code>
|
|
<dd>DCE thread support.
|
|
<br><dt><code>mach</code>
|
|
<dd>Generic MACH thread support, known to work on NeXTSTEP. (Please note
|
|
that the file needed to support this configuration, <code>gthr-mach.h</code>, is
|
|
missing and thus this setting will cause a known bootstrap failure.)
|
|
<br><dt><code>no</code>
|
|
<dd>This is an alias for <code>single</code>.
|
|
<br><dt><code>posix</code>
|
|
<dd>Generic POSIX thread support.
|
|
<br><dt><code>pthreads</code>
|
|
<dd>Same as <code>posix</code> on arm*-*-linux*, *-*-chorusos* and *-*-freebsd*
|
|
only. A future release of gcc might remove this alias or extend it
|
|
to all platforms.
|
|
<br><dt><code>rtems</code>
|
|
<dd>RTEMS thread support.
|
|
<br><dt><code>single</code>
|
|
<dd>Disable thread support, should work for all platforms.
|
|
<br><dt><code>solaris</code>
|
|
<dd>Sun Solaris 2 thread support.
|
|
<br><dt><code>vxworks</code>
|
|
<dd>VxWorks thread support.
|
|
<br><dt><code>win32</code>
|
|
<dd>Microsoft Win32 API thread support.
|
|
</dl>
|
|
|
|
<br><dt><code>--with-cpu=</code><var>cpu</var><code></code>
|
|
<dd>Specify which cpu variant the
|
|
compiler should generate code for by default. This is currently
|
|
only supported on some ports, specifically arm, powerpc, and
|
|
SPARC. If configure does not recognize the model name (e.g. arm700,
|
|
603e, or ultrasparc) you provide, please check the
|
|
<code>gcc/config.gcc</code> script for a complete list of supported models.
|
|
|
|
<br><dt><code>--enable-altivec</code>
|
|
<dd>Specify that the target supports AltiVec vector enhancements. This
|
|
option will adjust the ABI for AltiVec enhancements, as well as generate
|
|
AltiVec code when appropriate. This option is only available for
|
|
PowerPC systems.
|
|
|
|
<br><dt><code>--enable-target-optspace</code>
|
|
<dd>Specify that target
|
|
libraries should be optimized for code space instead of code speed.
|
|
This is the default for the m32r platform.
|
|
|
|
<br><dt><code>--disable-cpp</code>
|
|
<dd>Specify that a user visible <code>cpp</code> program should not be installed.
|
|
|
|
<br><dt><code>--with-cpp-install-dir=</code><var>dirname</var><code></code>
|
|
<dd>Specify that the user visible <code>cpp</code> program should be installed
|
|
in <code></code><var>prefix</var><code>/</code><var>dirname</var><code>/cpp</code>, in addition to <var>bindir</var>.
|
|
|
|
<br><dt><code>--enable-initfini-array</code>
|
|
<dd>Force the use of sections <code>.init_array</code> and <code>.fini_array</code>
|
|
(instead of <code>.init</code> and <code>.fini</code>) for constructors and
|
|
destructors. Option <code>--disable-initfini-array</code> has the
|
|
opposite effect. If neither option is specified, the configure script
|
|
will try to guess whether the <code>.init_array</code> and
|
|
<code>.fini_array</code> sections are supported and, if they are, use them.
|
|
|
|
<br><dt><code>--enable-maintainer-mode</code>
|
|
<dd>The build rules that
|
|
regenerate the GCC master message catalog <code>gcc.pot</code> 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 <code>--enable-maintainer-mode</code> will enable
|
|
this. Note that you need a recent version of the <code>gettext</code> tools
|
|
to do so.
|
|
|
|
<br><dt><code>--enable-version-specific-runtime-libs</code>
|
|
<dd>Specify
|
|
that runtime libraries should be installed in the compiler specific
|
|
subdirectory (<code></code><var>libsubdir</var><code></code>) rather than the usual places. In
|
|
addition, <code>libstdc++</code>'s include files will be installed in
|
|
<code></code><var>libsubdir</var><code>/include/g++</code> unless you overruled it by using
|
|
<code>--with-gxx-include-dir=</code><var>dirname</var><code></code>. Using this option is
|
|
particularly useful if you intend to use several versions of GCC in
|
|
parallel. This is currently supported by <code>libf2c</code> and
|
|
<code>libstdc++</code>, and is the default for <code>libobjc</code> which cannot be
|
|
changed in this case.
|
|
|
|
<br><dt><code>--enable-languages=</code><var>lang1</var><code>,</code><var>lang2</var><code>,...</code>
|
|
<dd>Specify that only a particular subset of compilers and
|
|
their runtime libraries should be built. For a list of valid values for
|
|
<var>langN</var> you can issue the following command in the
|
|
<code>gcc</code> directory of your GCC source tree:<br>
|
|
<pre class="example"> grep language= */config-lang.in
|
|
</pre>
|
|
Currently, you can use any of the following:
|
|
<code>ada</code>, <code>c</code>, <code>c++</code>, <code>f77</code>, <code>java</code>, <code>objc</code>.
|
|
Building the Ada compiler has special requirements, see below.<br>
|
|
If you do not pass this flag, all languages available in the <code>gcc</code>
|
|
sub-tree will be configured. Re-defining <code>LANGUAGES</code> when calling
|
|
<code>make bootstrap</code> <strong>does not</strong> work anymore, as those
|
|
language sub-directories might not have been configured!
|
|
|
|
<br><dt><code>--disable-libgcj</code>
|
|
<dd>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 <code>libgcj</code> isn't built, you
|
|
may need to port it; in this case, before modifying the top-level
|
|
<code>configure.in</code> so that <code>libgcj</code> is enabled by default on this platform,
|
|
you may use <code>--enable-libgcj</code> to override the default.
|
|
|
|
<br><dt><code>--with-dwarf2</code>
|
|
<dd>Specify that the compiler should
|
|
use DWARF 2 debugging information as the default.
|
|
|
|
<br><dt><code>--enable-win32-registry</code>
|
|
<dd><dt><code>--enable-win32-registry=</code><var>key</var><code></code>
|
|
<dd><dt><code>--disable-win32-registry</code>
|
|
<dd>The <code>--enable-win32-registry</code> option enables Windows-hosted GCC
|
|
to look up installations paths in the registry using the following key:
|
|
|
|
<pre class="smallexample"> <code>HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\</code><var>key</var><code></code>
|
|
</pre>
|
|
|
|
<p><var>key</var> defaults to GCC version number, and can be overridden by the
|
|
<code>--enable-win32-registry=</code><var>key</var><code></code> 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 <code>--disable-win32-registry</code>
|
|
option. This option has no effect on the other hosts.
|
|
|
|
<br><dt><code>--nfp</code>
|
|
<dd>Specify that the machine does not have a floating point unit. This
|
|
option only applies to <code>m68k-sun-sunos</code><var>n</var><code></code>. On any other
|
|
system, <code>--nfp</code> has no effect.
|
|
|
|
<br><dt><code>--enable-checking</code>
|
|
<dd><dt><code>--enable-checking=</code><var>list</var><code></code>
|
|
<dd>When you specify this option, the compiler is built to perform checking
|
|
of tree node types when referencing fields of that node, and some other
|
|
internal consistency checks. 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 on by default when building from CVS or snapshots,
|
|
but off for releases. More control over the checks may be had by
|
|
specifying <var>list</var>; the categories of checks available are
|
|
<code>misc</code>, <code>tree</code>, <code>gc</code>, <code>rtl</code>, <code>rtlflag</code>,
|
|
<code>gcac</code> and <code>valgrind</code>. The check <code>valgrind</code> requires the
|
|
external <code>valgrind</code> simulator, available from
|
|
<a href="http://developer.kde.org/~sewardj/">http://developer.kde.org/~sewardj/</a>. The default when <var>list</var> is
|
|
not specified is <code>misc,tree,gc,rtlflag</code>; the checks <code>rtl</code>,
|
|
<code>gcac</code> and <code>valgrind</code> are very expensive.
|
|
|
|
<br><dt><code>--enable-coverage</code>
|
|
<dd><dt><code>--enable-coverage=</code><var>level</var><code></code>
|
|
<dd>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</var> argument controls whether the compiler is built optimized or
|
|
not, values are <code>opt</code> and <code>noopt</code>. 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.
|
|
|
|
<br><dt><code>--enable-nls</code>
|
|
<dd><dt><code>--disable-nls</code>
|
|
<dd>The <code>--enable-nls</code> 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 <code>--disable-nls</code> option disables NLS.
|
|
|
|
<br><dt><code>--with-included-gettext</code>
|
|
<dd>If NLS is enabled, the <code>--with-included-gettext</code> option causes the build
|
|
procedure to prefer its copy of GNU <code>gettext</code>.
|
|
|
|
<br><dt><code>--with-catgets</code>
|
|
<dd>If NLS is enabled, and if the host lacks <code>gettext</code> but has the
|
|
inferior <code>catgets</code> interface, the GCC build procedure normally
|
|
ignores <code>catgets</code> and instead uses GCC's copy of the GNU
|
|
<code>gettext</code> library. The <code>--with-catgets</code> option causes the
|
|
build procedure to use the host's <code>catgets</code> in this situation.
|
|
|
|
<br><dt><code>--with-libiconv-prefix=</code><var>dir</var><code></code>
|
|
<dd>Search for libiconv header files in <code></code><var>dir</var><code>/include</code> and
|
|
libiconv library files in <code></code><var>dir</var><code>/lib</code>.
|
|
|
|
<br><dt><code>--with-system-zlib</code>
|
|
<dd>Use installed zlib rather than that included with GCC. This option
|
|
only applies if the Java front end is being built.
|
|
|
|
<br><dt><code>--enable-obsolete</code>
|
|
<dd>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.
|
|
|
|
<p>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.
|
|
</dl>
|
|
|
|
<p>Some options which only apply to building cross compilers:
|
|
<dl>
|
|
<dt><code>--with-sysroot</code>
|
|
<dd><dt><code>--with-sysroot=</code><var>dir</var><code></code>
|
|
<dd>Tells GCC to consider <var>dir</var> 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 <code>--with-headers</code> and
|
|
<code>--with-libs</code> that this option obsoletes. The default value,
|
|
in case <code>--with-sysroot</code> is not given an argument, is
|
|
<code>${gcc_tooldir}/sys-root</code>. If the specified directory is a
|
|
subdirectory of <code>${exec_prefix}</code>, then it will be found relative to
|
|
the GCC binaries if the installation tree is moved.
|
|
|
|
<br><dt><code>--with-headers</code>
|
|
<dd><dt><code>--with-headers=</code><var>dir</var><code></code>
|
|
<dd>Deprecated in favor of <code>--with-sysroot</code>.
|
|
Specifies that target headers are available when building a cross compiler.
|
|
The <var>dir</var> argument specifies a directory which has the target include
|
|
files. These include files will be copied into the <code>gcc</code> install
|
|
directory. <em>This option with the </em><var>dir</var><em> argument is required</em> when
|
|
building a cross compiler, if <code></code><var>prefix</var><code>/</code><var>target</var><code>/sys-include</code>
|
|
doesn't pre-exist. If <code></code><var>prefix</var><code>/</code><var>target</var><code>/sys-include</code> does
|
|
pre-exist, the <var>dir</var> argument may be omitted. <code>fixincludes</code>
|
|
will be run on these files to make them compatible with GCC.
|
|
<br><dt><code>--with-libs</code>
|
|
<dd><dt><code>--with-libs=``</code><var>dir1</var><code> </code><var>dir2</var><code> ... </code><var>dirN</var><code>''</code>
|
|
<dd>Deprecated in favor of <code>--with-sysroot</code>.
|
|
Specifies a list of directories which contain the target runtime
|
|
libraries. These libraries will be copied into the <code>gcc</code> install
|
|
directory. If the directory list is omitted, this option has no
|
|
effect.
|
|
<br><dt><code>--with-newlib</code>
|
|
<dd>Specifies that <code>newlib</code> is
|
|
being used as the target C library. This causes <code>__eprintf</code> to be
|
|
omitted from <code>libgcc.a</code> on the assumption that it will be provided by
|
|
<code>newlib</code>.
|
|
</dl>
|
|
|
|
<p>Note that each <code>--enable</code> option has a corresponding
|
|
<code>--disable</code> option and that each <code>--with</code> option has a
|
|
corresponding <code>--without</code> option.
|
|
|
|
<hr />
|
|
<p>
|
|
<a href="./index.html">Return to the GCC Installation page</a>
|
|
|
|
</body></html>
|
|
|