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 by cloning the repository, srcdir must refer to the top gcc directory, the one where the MAINTAINERS file 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 from 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.
To configure GCC:
% mkdir objdir % cd objdir % srcdir/configure [options] [target]
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.
--with-pkgversion=
versionThe default value is `GCC'.
--with-bugurl=
urlThe default value refers to the FSF's GCC bug tracker.
--with-documentation-root-url=
url/
character.
The default value is https://gcc.gnu.org/onlinedocs/.
--with-changes-root-url=
urlgcc-
version/changes.html
.
The url should end with a /
character.
The default value is https://gcc.gnu.org/.
Use 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.
Note that each --enable option has a corresponding --disable option and that each --with option has a corresponding --without option.
--prefix=
dirnameWe 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.
The following standard autoconf options are supported. Normally you should not need to use these options.
--exec-prefix=
dirname--bindir=
dirname--libdir=
dirname--libexecdir=
dirname--with-slibdir=
dirname--datarootdir=
dirname--infodir=
dirname--datadir=
dirname--docdir=
dirname--htmldir=
dirname--pdfdir=
dirname--mandir=
dirname--with-gxx-include-dir=
dirname--with-specs=
specs--program-prefix=
prefix--program-suffix=
suffix--program-transform-name=
patternAll 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=
dirnameYou 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.
--with-gcc-major-version-only
--with-native-system-header-dir=
dirname--enable-shared[=
package[,...]]
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', `ada', `libada', `libgo', `libobjc', and `libphobos'. Note `libiberty' does 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.
Contrast with --enable-host-shared, which affects host
code.
--enable-host-shared
This option is required when building the libgccjit.so library.
Contrast with --enable-shared, which affects target
libraries.
--with-gnu-as
The 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.
--with-as=
pathnameYou 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-ld=
pathname--with-stabs
--with-tls=
dialectgnu
or
gnu2
, which select between the original GNU dialect and the GNU TLS
descriptor-based dialect.
--enable-multiarch
--enable-sjlj-exceptions
setjmp
/longjmp
-based scheme for exceptions.
`configure' ordinarily picks the correct value based on the platform.
Only use this option if you are sure you need a different setting.
--enable-vtable-verify
--disable-gcov
--disable-multilib
Some targets provide finer-grained control over which multilibs are built (e.g., --disable-softfloat):
arm-*-*
m68*-*-*
mips*-*-*
msp430-*-*
powerpc*-*-*, rs6000*-*-*
--with-multilib-list=
list--without-multilib-list
aarch64*-*-*
ilp32
, and lp64
to enable ILP32 and LP64 run-time libraries, respectively. If
list is empty, then there will be no multilibs and only the
default run-time library will be built. If list is
default
or –with-multilib-list= is not specified, then the
default set of libraries is selected based on the value of
--target.
arm*-*-*
aprofile
and
rmprofile
to build multilibs for A or R and M architecture
profiles respectively. Note that, due to some limitation of the current
multilib framework, using the combined aprofile,rmprofile
multilibs selects in some cases a less optimal multilib than when using
the multilib profile for the architecture targetted. The special value
default
is also accepted and is equivalent to omitting the
option, i.e., only the default run-time library will be enabled.
list may instead contain @name
, to use the multilib
configuration Makefile fragment name in gcc/config/arm in
the source tree (it is part of the corresponding sources, after all).
It is recommended, but not required, that files used for this purpose to
be named starting with t-ml-, to make their intended purpose
self-evident, in line with GCC conventions. Such files enable custom,
user-chosen multilib lists to be configured. Whether multiple such
files can be used together depends on the contents of the supplied
files. See gcc/config/arm/t-multilib and its supplementary
gcc/config/arm/t-*profile files for an example of what such
Makefile fragments might look like for this version of GCC. The macros
expected to be defined in these fragments are not stable across GCC
releases, so make sure they define the MULTILIB
-related macros
expected by the version of GCC you are building.
See “Target Makefile Fragments” in the internals manual.
The table below gives the combination of ISAs, architectures, FPUs and
floating-point ABIs for which multilibs are built for each predefined
profile. The union of these options is considered when specifying both
aprofile
and rmprofile
.
Option | aprofile | rmprofile
|
ISAs | -marm and -mthumb
| -mthumb
|
Architectures | default architecture-march=armv7-a -march=armv7ve -march=armv8-a | default architecture-march=armv6s-m -march=armv7-m -march=armv7e-m -march=armv8-m.base -march=armv8-m.main -march=armv7
|
FPUs | none-mfpu=vfpv3-d16 -mfpu=neon -mfpu=vfpv4-d16 -mfpu=neon-vfpv4 -mfpu=neon-fp-armv8
| none-mfpu=vfpv3-d16 -mfpu=fpv4-sp-d16 -mfpu=fpv5-sp-d16 -mfpu=fpv5-d16 |
floating-point ABIs | -mfloat-abi=soft -mfloat-abi=softfp -mfloat-abi=hard
| -mfloat-abi=soft -mfloat-abi=softfp -mfloat-abi=hard
|
riscv*-*-*
rv32gc
or rv64gc
. This will build a single multilib for the
specified architecture and ABI pair. If --with-multilib-list
is not
given, then a default set of multilibs is selected based on the value of
--target. This is usually a large set of multilibs.
sh*-*-*
sh*
or m*
(in which case they match the compiler option
for that processor). The list should not contain any endian options -
these are handled by --with-endian.
If list is empty, then there will be no multilibs for extra processors. The multilib for the secondary endian remains enabled.
As a special case, if an entry in the list starts with a !
(exclamation point), then it is added to the list of excluded multilibs.
Entries of this sort should be compatible with `MULTILIB_EXCLUDES'
(once the leading !
has been stripped).
If --with-multilib-list is not given, then a default set of multilibs is selected based on the value of --target. This is usually the complete set of libraries, but some targets imply a more specialized subset.
Example 1: to configure a compiler for SH4A only, but supporting both endians, with little endian being the default:
--with-cpu=sh4a --with-endian=little,big --with-multilib-list=
Example 2: to configure a compiler for both SH4A and SH4AL-DSP, but with only little endian SH4AL:
--with-cpu=sh4a --with-endian=little,big \ --with-multilib-list=sh4al,!mb/m4al
x86-64-*-linux*
m32
, m64
and
mx32
to enable 32-bit, 64-bit and x32 run-time libraries,
respectively. If list is empty, then there will be no multilibs
and only the default run-time library will be enabled.
If --with-multilib-list is not given, then only 32-bit and 64-bit run-time libraries will be enabled.
--with-multilib-generator=
configEvery config is constructed with four components: architecture string, ABI, reuse rule with architecture string and reuse rule with sub-extension.
Example 1: Add multi-lib suppport for rv32i with ilp32.
rv32i-ilp32--
Example 2: Add multi-lib suppport for rv32i with ilp32 and rv32imafd with ilp32.
rv32i-ilp32--;rv32imafd-ilp32--
Example 3: Add multi-lib suppport for rv32i with ilp32; rv32im with ilp32 and rv32ic with ilp32 will reuse this multi-lib set.
rv32i-ilp32-rv32im-c
Example 4: Add multi-lib suppport for rv64ima with lp64; rv64imaf with lp64, rv64imac with lp64 and rv64imafc with lp64 will reuse this multi-lib set.
rv64ima-lp64--f,c,fc
--with-endian=
endiansendians may be one of the following:
big
little
big,little
little,big
--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=
libaix
dce
lynx
mipssde
no
posix
rtems
single
tpf
vxworks
win32
--enable-tls
--disable-tls
--disable-tm-clone-registry
--with-cpu=
cpu--with-cpu-32=
cpu--with-cpu-64=
cpu--with-schedule=
cpu--with-arch=
cpu--with-arch-32=
cpu--with-arch-64=
cpu--with-tune=
cpu--with-tune-32=
cpu--with-tune-64=
cpu--with-abi=
abi--with-fpu=
type--with-float=
type--with-mode=
mode--with-stack-offset=
num--with-fpmath=
isa--with-fp-32=
mode32
xx
64
--with-odd-spreg-32
--without-odd-spreg-32
--with-nan=
encodinglegacy
2008
--with-divide=
typetraps
breaks
--with-llsc
--without-llsc
--with-synci
--without-synci
--with-lxc1-sxc1
--without-lxc1-sxc1
addu
instruction or as part of the address calculation
in lwxc1
type instructions. This assumption holds true in a
pure 32-bit environment and can hold true in a 64-bit environment if
the address space is accurately set to be 32-bit for o32 and n32.
--with-madd4
--without-madd4
madd4
instruction
family can be problematic when targeting a combination of cores that
implement these instructions differently. There are two known cores
that implement these as fused operations instead of unfused (where
unfused is normally expected). Disabling these instructions is the
only way to ensure compatible code is generated; this will incur
a performance penalty.
--with-mips-plt
--with-stack-clash-protection-guard-size=
size--enable-__cxa_atexit
--enable-gnu-indirect-function
ifunc
attribute. This option is
currently only available on systems with GNU libc on certain targets.
--enable-target-optspace
--with-cpp-install-dir=
dirname--enable-comdat
--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-link-mutex
--enable-link-serialization
--enable-maintainer-mode
gettext
tools
to do so.
--disable-bootstrap
--enable-bootstrap
--enable-generated-files-in-srcdir
If you configure with --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.
--enable-version-specific-runtime-libs
--with-aix-soname=`
aix', `
svr4' or `
both'
Shared Object
files as members of unversioned Archive Library
files named
`lib.a') causes numerous headaches for package managers. However,
Import Files
as members of Archive Library
files allow for
filename-based versioning of shared libraries as seen on Linux/SVR4,
where this is called the "SONAME". But as they prevent static linking,
Import Files
may be used with Runtime Linking
only, where the
linker does search for `libNAME.so' before `libNAME.a' library
filenames with the `-lNAME' linker flag.
For detailed information please refer to the AIX ld Command reference.
As long as shared library creation is enabled, upon:
--with-aix-soname=aix
--with-aix-soname=both
Shared Archive Library
file is created:
Shared Object
file as archive member named
`libNAME.so.V' (except for `libgcc_s', where the Shared
Object
file is named `shr.o' for backwards compatibility), which
dlopen("libNAME.a(libNAME.so.V)", RTLD_MEMBER)
Static Archive
Library
file is needed
--with-aix-soname=both
--with-aix-soname=svr4
Shared Archive Library
file is created:
Shared Object
file as archive member named
`shr.o', which
-G linker flag
F_LOADONLY
flag set
dlopen("libNAME.so.V(shr.o)",
RTLD_MEMBER)
Import File
as archive member named `shr.imp',
which
Loader Section
of subsequent binaries
`
weak' Keyword
Shared Archive Library
file
ld Command
to find `lib.so.V(shr.imp)' via
the `-lNAME' argument (requires Runtime Linking
to be enabled)
dlopen("libNAME.so(shr.o)",
RTLD_MEMBER)
As long as static library creation is enabled, upon:
--with-aix-soname=svr4
Static Archive Library
is created:
Static Object
files as archive members, which
While the aix-soname=`svr4' option does not create Shared Object
files as members of unversioned Archive Library
files any more, package
managers still are responsible to
transfer Shared Object
files
found as member of a previously installed unversioned Archive Library
file into the newly installed Archive Library
file with the same
filename.
WARNING: Creating Shared Object
files with Runtime Linking
enabled may bloat the TOC, eventually leading to TOC overflow
errors,
requiring the use of either the -Wl,-bbigtoc linker flag (seen to
break with the GDB
debugger) or some of the TOC-related compiler flags,
see “RS/6000 and PowerPC Options” in the main manual.
--with-aix-soname is currently supported by `libgcc_s' only, so this option is still experimental and not for normal use yet.
Default is the traditional behavior --with-aix-soname=`aix'.
--enable-languages=
lang1,
lang2,...
grep ^language= */config-lang.in
Currently, you can use any of the following:
all
, default
, ada
, c
, c++
, d
,
fortran
, go
, jit
, lto
, objc
, obj-c++
.
Building the Ada compiler has special requirements, see below.
If you do not pass this flag, or specify the option default
, then the
default languages available in the gcc sub-tree will be configured.
Ada, D, Go, Jit, and Objective-C++ are not default languages. LTO is not a
default language, but is built by default because --enable-lto is
enabled by default. The other languages are default languages. If
all
is specified, then all available languages are built. An
exception is jit
language, which requires
--enable-host-shared to be included with all
.
--enable-stage1-languages=
lang1,
lang2,...
all
will select all
of the languages enabled by --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 make
stage1-bubble all-target, or run the testsuite on the stage-1 compiler
for the specified languages using make stage1-start check-gcc.
--disable-libada
--disable-libsanitizer
--disable-libssp
--disable-libquadmath
--disable-libquadmath-support
libgfortran
do not add
support for libquadmath
on systems supporting it.
--disable-libgomp
--disable-libvtv
--with-dwarf2
--with-advance-toolchain=
at--enable-targets=all
--enable-targets=
target_list--enable-default-pie
--enable-secureplt
--enable-default-ssp
--enable-cld
--enable-large-address-aware
--enable-win32-registry
--enable-win32-registry=
key--disable-win32-registry
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
--enable-werror
--disable-werror
--enable-werror=yes
--enable-werror=no
--enable-checking
--disable-checking
--enable-checking=
listWhen the option is not specified, the active set of checks depends on context. Namely, bootstrap stage 1 defaults to `--enable-checking=yes', builds from release branches or release archives default to `--enable-checking=release', and otherwise `--enable-checking=yes,extra' is used. When the option is specified without a list, the result is the same as `--enable-checking=yes'. Likewise, `--disable-checking' is equivalent to `--enable-checking=no'.
The categories of checks available in list are `yes' (most common checks `assert,misc,gc,gimple,rtlflag,runtime,tree,types'), `no' (no checks at all), `all' (all but `valgrind'), `release' (cheapest checks `assert,runtime') or `none' (same as `no'). `release' checks are always on and to disable them `--disable-checking' or `--enable-checking=no[,<other checks>]' must be explicitly requested. Disabling assertions makes the compiler and runtime slightly faster but increases the risk of undetected internal errors causing wrong code to be generated.
Individual checks can be enabled with these flags: `assert', `df', `extra', `fold', `gc', `gcac', `gimple', `misc', `rtl', `rtlflag', `runtime', `tree', `types' and `valgrind'. `extra' extends `misc' checking with extra checks that might affect code generation and should therefore not differ between stage1 and later stages in bootstrap.
The `valgrind' check requires the external valgrind simulator,
available from https://valgrind.org. The `rtl' checks are
expensive and the `df', `gcac' and `valgrind' checks are very
expensive.
--disable-stage1-checking
--enable-stage1-checking
--enable-stage1-checking=
list--enable-coverage
--enable-coverage=
level--enable-gather-detailed-mem-stats
--enable-valgrind-annotations
--enable-nls
--disable-nls
--with-included-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--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.
--enable-decimal-float
--enable-decimal-float=yes
--enable-decimal-float=no
--enable-decimal-float=bid
--enable-decimal-float=dpd
--disable-decimal-float
--enable-fixed-point
--disable-fixed-point
--with-long-double-128
long double
type should be 128-bit by default on selected
GNU/Linux architectures. If using --without-long-double-128
,
long double
will be by default 64-bit, the same as double
type.
When neither of these configure options are used, the default will be
128-bit long double
when built against GNU C Library 2.4 and later,
64-bit long double
otherwise.
--with-long-double-format=ibm
--with-long-double-format=ieee
long double
uses the IBM extended double format
or the IEEE 128-bit floating point format on PowerPC Linux systems.
This configuration switch will only work on little endian PowerPC
Linux systems and on big endian 64-bit systems where the default cpu
is at least power7 (i.e. --with-cpu=power7,
--with-cpu=power8, or --with-cpu=power9 is used).
If you use the --with-long-double-64 configuration option, the --with-long-double-format=ibm and --with-long-double-format=ieee options are ignored.
The default long double
format is to use IBM extended double.
Until all of the libraries are converted to use IEEE 128-bit floating
point, it is not recommended to use
--with-long-double-format=ieee.
On little endian PowerPC Linux systems, if you explicitly set the
long double
type, it will build multilibs to allow you to
select either long double
format, unless you disable multilibs
with the --disable-multilib
option. At present,
long double
multilibs are not built on big endian PowerPC Linux
systems. If you are building multilibs, you will need to configure
the compiler using the --with-system-zlib option.
If you do not set the long double
type explicitly, no multilibs
will be generated.
--enable-fdpic
--with-gmp=
pathname--with-gmp-include=
pathname--with-gmp-lib=
pathname--with-mpfr=
pathname--with-mpfr-include=
pathname--with-mpfr-lib=
pathname--with-mpc=
pathname--with-mpc-include=
pathname--with-mpc-lib=
pathnameThese flags are applicable to the host platform only. When building
a cross compiler, they will not be used to configure target libraries.
--with-isl=
pathname--with-isl-include=
pathname--with-isl-lib=
pathnameThese flags are applicable to the host platform only. When building
a cross compiler, they will not be used to configure target libraries.
--with-stage1-ldflags=
flags--with-stage1-libs=
libs--with-boot-ldflags=
flags--with-boot-libs=
libs--with-debug-prefix-map=
map--enable-linker-build-id
--with-linker-hash-style=
choice--enable-gnu-unique-object
--disable-gnu-unique-object
--with-diagnostics-color=
choice--with-diagnostics-urls=
choice--enable-lto
--disable-lto
--enable-linker-plugin-configure-flags=FLAGS
--enable-linker-plugin-flags=FLAGS
% srcdir/configure \ --host=x86_64-pc-linux-gnu \ --enable-linker-plugin-configure-flags=--host=i686-pc-linux-gnu \ --enable-linker-plugin-flags='CC=gcc\ -m32\ -Wl,-rpath,[...]/i686-pc-linux-gnu/lib'
--with-plugin-ld=
pathname--enable-canonical-system-headers
--disable-canonical-system-headers
--with-glibc-version=
major.
minorIf GCC is configured with some multilibs that use glibc and some that
do not, this option applies only to the multilibs that use glibc.
However, such configurations may not work well as not all the relevant
configuration in GCC is on a per-multilib basis.
--enable-as-accelerator-for=
target--enable-offload-targets=
target1[=
path1],...,
targetN[=
pathN]
% srcdir/configure \ --enable-offload-targets=x86_64-intelmicemul-linux-gnu=/path/to/x86_64/compiler,nvptx-none
--with-hsa-runtime=
pathname--with-hsa-runtime-include=
pathname--with-hsa-runtime-lib=
pathname--enable-cet
--disable-cet
--enable-cet
is specified target libraries are configured
to add -fcf-protection and, if needed, other target
specific options to a set of building options.
--enable-cet=auto
is default. CET is enabled on Linux/x86 if
target binutils supports Intel CET
instructions and disabled
otherwise. In this case, the target libraries are configured to get
additional -fcf-protection option.
--with-riscv-attribute=`
yes', `
no' or `
default'
The option is disabled by default. It is enabled on RISC-V/ELF (bare-metal)
target if target binutils supported.
--enable-s390-excess-float-precision
--disable-s390-excess-float-precision
--std=c99
or
-fexcess-precision=standard
are given).
For a native build and cross compiles that have target headers, the option's default is derived from glibc's behavior. When glibc clamps float_t to double, GCC follows and enables the option. For other cross compiles, the default is disabled.
The following options only apply to building cross compilers.
--with-toolexeclibdir=
dir--with-sysroot
--with-sysroot=
dirThis option affects the system root for the compiler used to build
target libraries (which runs on the build system) and the compiler newly
installed with make install
; it does not affect the compiler which is
used to build GCC itself.
If you specify the --with-native-system-header-dir=dirname
option then the compiler will search that directory within dirname for
native system headers rather than the default /usr/include.
--with-build-sysroot
--with-build-sysroot=
dirThis 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.
If you specify the --with-native-system-header-dir=dirname
option then the compiler will search that directory within dirname for
native system headers rather than the default /usr/include.
--with-headers
--with-headers=
dir--without-headers
--with-libs
--with-libs="
dir1 dir2 ...
dirN"
--with-newlib
__eprintf
to be
omitted from libgcc.a on the assumption that it will be provided by
`newlib'.
--with-avrlibc
__addsf3
to be omitted from libgcc.a on
the assumption that it will be provided by libm.a. For more
technical details, cf. PR54461.
It is not supported for
RTEMS configurations, which currently use newlib. The option is
supported since version 4.7.2 and is the default in 4.8.0 and newer.
--with-double={32|64|32,64|64,32}
--with-long-double={32|64|32,64|64,32|double}
--with-double-comparison={tristate|bool|libf7}
DFmode
).
The GCC default is `tristate'. If the floating point
implementation returns a boolean instead, set it to `bool'.
--with-libf7={libgcc|math|math-symbols|no}
__
(two underscores)
prepended to the symbol names as specified by math.h.
`math-symbols' also defines weak aliases for the functions
declared in math.h. However, --with-libf7
won't
install no math.h header file whatsoever, this file must come
from elsewhere. This option sets --with-double-comparison
to `bool'.
--with-nds32-lib=
library--with-build-time-tools=
dirFor example, on an `ia64-hp-hpux' system, you may have the GNU assembler and linker in /usr/bin, and the native tools in a different path, and build a toolchain that expects to find the native tools in /usr/bin.
When you use this option, you should ensure that dir includes ar, as, ld, nm, ranlib and strip if necessary, and possibly objdump. Otherwise, GCC may use an inconsistent set of tools.
Sometimes, it might be necessary to override the result of some configure test, for example in order to ease porting to a new system or work around a bug in a test. The toplevel configure script provides three variables for this:
build_configargs
host_configargs
target_configargs
In order to avoid shell and make quoting issues for complex overrides, you can pass a setting for CONFIG_SITE and set variables in the site file.
The following options apply to the build of the Objective-C runtime library.
--enable-objc-gc
--with-target-bdw-gc=
list--with-target-bdw-gc-include=
list--with-target-bdw-gc-lib=
listThe options --with-target-bdw-gc-include and --with-target-bdw-gc-lib must always be specified together for each multilib variant and they take precedence over --with-target-bdw-gc. If --with-target-bdw-gc-include is missing values for a multilib, then the value for the default multilib is used (e.g. `--with-target-bdw-gc-include=/opt/bdw-gc/include' `--with-target-bdw-gc-lib=/opt/bdw-gc/lib64,32=/opt-bdw-gc/lib32'). If none of these options are specified, the library is assumed in default locations.
The following options apply to the build of the D runtime library.
--enable-libphobos-checking
--disable-libphobos-checking
--enable-libphobos-checking=
listThe categories of checks available in list are `yes' (compiles libphobos with -fno-release), `no' (compiles libphobos with -frelease), `all' (same as `yes'), `none' or `release' (same as `no').
Individual checks available in list are `assert' (compiles libphobos
with an extra option -fassert).
--with-libphobos-druntime-only
--with-libphobos-druntime-only=
choiceWhen the option is not specified, the default choice `auto' means that it
is inferred whether the target has support for the phobos standard library.
When the option is specified without a choice, the result is the same as
`--with-libphobos-druntime-only=yes'.
--with-target-system-zlib