We use srcdir to refer to the toplevel source directory for GCC; we use objdir to refer to the toplevel build/object directory.
If you obtained the sources via CVS, srcdir must refer to the top
gcc directory, the one where the MAINTAINERS can be found,
and not its gcc subdirectory, otherwise the build will fail.
If either srcdir or objdir is located on an automounted NFS
file system, the shell's built-in pwd command will return
temporary pathnames. Using these can lead to various sorts of build
problems. To avoid this issue, set the PWDCMD environment
variable to an automounter-aware pwd command, e.g.,
pawd or amq -w, during the configuration and build
phases.
First, we highly recommend that GCC be built into a separate directory than the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn't get extensive testing; building where objdir is a subdirectory of srcdir is unsupported.
If you have previously built GCC in the same directory for a
different target machine, do make distclean to delete all files
that might be invalid. One of the files this deletes is Makefile;
if make distclean complains that 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 objdir, you should
simply use a different objdir for each target.
Second, when configuring a native system, either cc or
gcc must be in your path or you must set CC in
your environment before running configure. Otherwise the configuration
scripts may fail.
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 host/target specific installation notes.
To configure GCC:
% mkdir objdir
% cd objdir
% srcdir/configure [options] [target]
--target=target--target=targetUse options to override several configure time options for
GCC. A list of supported options follows; configure
--help may list other options, but those not listed below may not
work and should not normally be used.
--prefix=dirname/usr/local.
We highly recommend against dirname being the same or a
subdirectory of objdir or vice versa. If specifying a directory
beneath a user's home directory tree, some shells will not expand
dirname correctly if it contains the ~ metacharacter; use
$HOME instead.
These additional options control where certain parts of the distribution are installed. Normally you should not need to use these options.
--exec-prefix=dirname--bindir=dirnamegcc and g++). The default is
/bin.
--libdir=dirname/lib.
--with-slibdir=dirname--infodir=dirname/info.
--datadir=dirname/share.
--mandir=dirname/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.)
--with-gxx-include-dir=dirname/include/g++-v3.
--program-prefix=prefix--program-prefix=foo- would result in gcc
being installed as /usr/local/bin/foo-gcc.
--program-suffix=suffix--program-suffix=-3.1
would result in gcc being installed as
/usr/local/bin/gcc-3.1.
--program-transform-name=patternsed script pattern to be applied to the names
of programs to install in bindir (see above). pattern has to
consist of one or more basic sed editing commands, separated by
semicolons. For example, if you want the gcc program name to be
transformed to the installed program /usr/local/bin/myowngcc and
the g++ program name to be transformed to
/usr/local/bin/gspecial++ without changing other program names,
you could use the pattern
--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, prefix (and suffix) are prepended (appended) before further transformations can happen with a special transformation script 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
i686-pc-linux-gnu-gcc. All of the above transformations happen
before the target alias is prepended to the name - so, specifying
--program-prefix=foo- and program-suffix=-3.1, the
resulting binary would be installed as
/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.
--with-local-prefix=dirname/usr/local. Specify this option if you want the compiler to
search directory /include for locally installed
header files instead of /usr/local/include.
You should specify --with-local-prefix only if your
site has a different convention (not /usr/local) for where to put
site-specific files.
The default value for --with-local-prefix is /usr/local
regardless of the value of --prefix. Specifying
--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 --prefix is to specify where to install
GCC. The local header files in /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 --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 -I directory options to the
compiler command line, to ensure that directories containing installed
packages' headers are searched. When 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
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 /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
--program-prefix, --program-suffix and
--program-transform-name options to install multiple versions
into a single directory, but it may be simpler to use different prefixes
and the --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 LIBRARY_PATH).
The same value can be used for both --with-local-prefix and
--prefix provided it is not /usr. This can be used
to avoid the default search of /usr/local/include.
Do not specify /usr as the --with-local-prefix!
The directory you use for --with-local-prefix 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 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.
--enable-shared[=package[,...]]
libobjc which is built as a static library only by
default.
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
libgcc (also known as gcc), libstdc++ (not
libstdc++-v3), libffi, zlib, boehm-gc and
libjava. Note that libobjc does not recognize itself by
any name, so, if you list package names in --enable-shared,
you will only get static Objective-C libraries. libf2c and
libiberty do not support shared libraries at all.
Use --disable-shared to build only static libraries. Note that
--disable-shared does not accept a list of package names as
argument, only --enable-shared does.
--with-gnu-as
--with-gnu-as.) If you have more than one
assembler installed on your system, you may want to use this option in
connection with --with-as=pathnameThe following systems are the only ones where it makes a difference
whether you use the GNU assembler. On any other system,
--with-gnu-as has no effect.
hppa1.0-any-anyhppa1.1-any-anyi386-any-sysv
m68k-bull-sysv
m68k-hp-hpux
m68000-hp-hpux
m68000-att-sysv
-lynx-lynxos
mips-anysparc-sun-solaris2.anysparc64-any-solaris2.anyOn the systems listed above (except for the HP-PA, the SPARC, for ISC on
the 386, and for mips-sgi-irix5.*), if you use the GNU assembler,
you should also use the GNU linker (and specify --with-gnu-ld).
--with-as=pathname/lib/gcc-lib/target/version/usr/local unless overridden by the
--prefix=pathnamesparc-sun-solaris2.7, and
version denotes the GCC version, such as 3.0.
/usr/ccs/bin on
Sun Solaris 2).
PATH. You may
want to use --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.
--with-gnu-ld
--with-gnu-as
but for the linker.
--with-ld=pathname--with-as
but for the linker.
--with-stabs
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 --with-stabs when you configure GCC.
No matter which default you choose when you configure GCC, the user
can use the -gcoff and -gstabs+ options to specify explicitly
the debug format for a particular compilation.
--with-stabs is meaningful on the ISC system on the 386, also, if
--with-gas is used. It selects use of stabs debugging
information embedded in COFF output. This kind of debugging information
supports C++ well; ordinary COFF debugging information does not.
--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.
--disable-multilib
Some targets provide finer-grained control over which multilibs are built
(e.g., --disable-softfloat):
arc-*-elf*
arm-*-*
m68*-*-*
mips*-*-*
powerpc*-*-*, rs6000*-*-*
--enable-threads
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, --enable-threads is an
alias for --enable-threads=single.
--disable-threads
--enable-threads=single.
--enable-threads=libaix
dce
mach
gthr-mach.h, is
missing and thus this setting will cause a known bootstrap failure.)
no
single.
posix
pthreads
posix on arm*-*-linux*, *-*-chorusos* and *-*-freebsd*
only. A future release of gcc might remove this alias or extend it
to all platforms.
rtems
single
solaris
vxworks
win32
--with-cpu=cpugcc/config.gcc script for a complete list of supported models.
--enable-altivec
--enable-target-optspace
--disable-cpp
cpp program should not be installed.
--with-cpp-install-dir=dirnamecpp program should be installed
in /dirname/cpp, in addition to bindir.
--enable-initfini-array
.init_array and .fini_array
(instead of .init and .fini) for constructors and
destructors. Option --disable-initfini-array has the
opposite effect. If neither option is specified, the configure script
will try to guess whether the .init_array and
.fini_array sections are supported and, if they are, use them.
--enable-maintainer-mode
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 --enable-maintainer-mode will enable
this. Note that you need a recent version of the gettext tools
to do so.
--enable-version-specific-runtime-libs
libstdc++'s include files will be installed in
/include/g++ unless you overruled it by using
--with-gxx-include-dir=dirnamelibf2c and
libstdc++, and is the default for libobjc which cannot be
changed in this case.
--enable-languages=lang1,lang2,...
gcc directory of your GCC source tree: grep language= */config-lang.in
Currently, you can use any of the following:
ada, c, c++, f77, java, objc.
Building the Ada compiler has special requirements, see below.gcc
sub-tree will be configured. Re-defining LANGUAGES when calling
make bootstrap does not work anymore, as those
language sub-directories might not have been configured!
--disable-libgcj
libgcj isn't built, you
may need to port it; in this case, before modifying the top-level
configure.in so that libgcj is enabled by default on this platform,
you may use --enable-libgcj to override the default.
--with-dwarf2
--enable-win32-registry
--enable-win32-registry=key--disable-win32-registry
--enable-win32-registry option enables Windows-hosted GCC
to look up installations paths in the registry using the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\key
key defaults to GCC version number, and can be overridden by the
--enable-win32-registry=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 --disable-win32-registry
option. This option has no effect on the other hosts.
--nfp
m68k-sun-sunosn--nfp has no effect.
--enable-checking
--enable-checking=listmisc, tree, gc, rtl, rtlflag,
gcac and valgrind. The check valgrind requires the
external valgrind simulator, available from
http://developer.kde.org/~sewardj/. The default when list is
not specified is misc,tree,gc,rtlflag; the checks rtl,
gcac and valgrind are very expensive.
--enable-coverage
--enable-coverage=levelopt and 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.
--enable-nls
--disable-nls
--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 --disable-nls option disables NLS.
--with-included-gettext
--with-included-gettext option causes the build
procedure to prefer its copy of GNU gettext.
--with-catgets
gettext but has the
inferior catgets interface, the GCC build procedure normally
ignores catgets and instead uses GCC's copy of the GNU
gettext library. The --with-catgets option causes the
build procedure to use the host's catgets in this situation.
--with-libiconv-prefix=dir/include and
libiconv library files in /lib.
--with-system-zlib
--enable-obsolete
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.
Some options which only apply to building cross compilers:
--with-sysroot
--with-sysroot=dir--with-headers and
--with-libs that this option obsoletes. The default value,
in case --with-sysroot is not given an argument, is
${gcc_tooldir}/sys-root. If the specified directory is a
subdirectory of ${exec_prefix}, then it will be found relative to
the GCC binaries if the installation tree is moved.
--with-headers
--with-headers=dir--with-sysroot.
Specifies that target headers are available when building a cross compiler.
The dir argument specifies a directory which has the target include
files. These include files will be copied into the gcc install
directory. This option with the dir argument is required when
building a cross compiler, if /target/sys-include
doesn't pre-exist. If /target/sys-include does
pre-exist, the dir argument may be omitted. fixincludes
will be run on these files to make them compatible with GCC.
--with-libs
--with-libs=``dir1 dir2 ... dirN''
--with-sysroot.
Specifies a list of directories which contain the target runtime
libraries. These libraries will be copied into the gcc install
directory. If the directory list is omitted, this option has no
effect.
--with-newlib
newlib is
being used as the target C library. This causes __eprintf to be
omitted from libgcc.a on the assumption that it will be provided by
newlib.
Note that each --enable option has a corresponding
--disable option and that each --with option has a
corresponding --without option.