diff -Nur gcc-4.9.3.orig/INSTALL/binaries.html gcc-4.9.3/INSTALL/binaries.html --- gcc-4.9.3.orig/INSTALL/binaries.html 2015-06-26 19:59:20.000000000 +0200 +++ gcc-4.9.3/INSTALL/binaries.html 1970-01-01 01:00:00.000000000 +0100 @@ -1,164 +0,0 @@ - - - - - -Installing GCC - - - - - - - - - - - - - -

Installing GCC

- - - - - - - - - - - - - - - - - - - - - - - - - - -

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. -

- - -
-

Return to the GCC Installation page -

- - - - - - - - - diff -Nur gcc-4.9.3.orig/INSTALL/build.html gcc-4.9.3/INSTALL/build.html --- gcc-4.9.3.orig/INSTALL/build.html 2015-06-26 19:59:18.000000000 +0200 +++ gcc-4.9.3/INSTALL/build.html 1970-01-01 01:00:00.000000000 +0100 @@ -1,457 +0,0 @@ - - - - - -Installing GCC - - - - - - - - - - - - - -

Installing GCC

- - - - - - - - - - - - - - - - - - - - - - -

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 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 ---disable-werror. -

-

On certain old systems, defining certain environment variables such as -CC can interfere with the functioning of 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 fixincludes if the -System V file system doesn’t support symbolic links. These problems -result in a failure to fix the declaration of size_t in -sys/types.h. If you find that 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 -*.l files, you need the Flex lexical analyzer generator -installed. If you do not modify *.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. -

- -

Building a native compiler

- -

For a native build, the default configuration is to perform -a 3-stage bootstrap of the compiler when ‘make’ is invoked. -This will build the entire GCC system and ensure that it compiles -itself correctly. It can be disabled with the --disable-bootstrap -parameter to ‘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: -

- - -

If you are short on disk space you might consider ‘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 BOOT_CFLAGS on the command line when -doing ‘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.) -

-
-
make BOOT_CFLAGS='-O' bootstrap
-
- -

You can place non-default optimization flags into BOOT_CFLAGS; they -are less well tested here than the default of ‘-g -O2’, but should -still work. In a few cases, you may find that you need to specify special -flags such as -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 BOOT_CFLAGS to avoid the parts -of the stage1 compiler that were miscompiled, or by using ‘make -bootstrap4’ to increase the number of stages of bootstrap. -

-

BOOT_CFLAGS does not apply to bootstrapped target libraries. -Since these are always compiled with the compiler currently being -bootstrapped, you can use 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 STAGE1_TFLAGS to this end. -

-

If you used the flag --enable-languages=… 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 LANGUAGES when calling ‘make’ -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 Makefile.) -

-

If you do not want to bootstrap your compiler, you can configure with ---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 -powerpc-unknown-linux-gnu toolchain on a -powerpc64-unknown-linux-gnu host. In this case, pass ---enable-bootstrap to the configure script. -

-

BUILD_CONFIG can be used to bring in additional customization -to the build. It can be set to a whitespace-separated list of names. -For each such NAME, top-level config/NAME.mk will -be included by the top-level Makefile, bringing in any settings -it contains. The default BUILD_CONFIG can be set using the -configure option --with-build-config=NAME.... Some -examples of supported build configurations are: -

-
-
‘bootstrap-O1’
-

Removes any -O-started option from BOOT_CFLAGS, and adds --O1 to it. ‘BUILD_CONFIG=bootstrap-O1’ is equivalent to -‘BOOT_CFLAGS='-g -O1'’. -

-
-
‘bootstrap-O3’
-

Analogous to bootstrap-O1. -

-
-
‘bootstrap-lto’
-

Enables Link-Time Optimization for host tools during bootstrapping. -‘BUILD_CONFIG=bootstrap-lto’ is equivalent to adding --flto to ‘BOOT_CFLAGS’. -

-
-
‘bootstrap-debug’
-

Verifies that the compiler generates the same executable code, whether -or not it is asked to emit debug information. To this end, this -option builds stage2 host programs without debug information, and uses -contrib/compare-debug to compare them with the stripped stage3 -object files. If BOOT_CFLAGS is overridden so as to not enable -debug information, stage2 will have it, and stage3 won’t. This option -is enabled by default when GCC bootstrapping is enabled, if -strip can turn object files compiled with and without debug -info into identical object files. In addition to better test -coverage, this option makes default bootstraps faster and leaner. -

-
-
‘bootstrap-debug-big’
-

Rather than comparing stripped object files, as in -bootstrap-debug, this option saves internal compiler dumps -during stage2 and stage3 and compares them as well, which helps catch -additional potential problems, but at a great cost in terms of disk -space. It can be specified in addition to ‘bootstrap-debug’. -

-
-
‘bootstrap-debug-lean’
-

This option saves disk space compared with bootstrap-debug-big, -but at the expense of some recompilation. Instead of saving the dumps -of stage2 and stage3 until the final compare, it uses --fcompare-debug to generate, compare and remove the dumps -during stage3, repeating the compilation that already took place in -stage2, whose dumps were not saved. -

-
-
‘bootstrap-debug-lib’
-

This option tests executable code invariance over debug information -generation on target libraries, just like bootstrap-debug-lean -tests it on host programs. It builds stage3 libraries with --fcompare-debug, and it can be used along with any of the -bootstrap-debug options above. -

-

There aren’t -lean or -big counterparts to this option -because most libraries are only build in stage3, so bootstrap compares -would not get significant coverage. Moreover, the few libraries built -in stage2 are used in stage3 host programs, so we wouldn’t want to -compile stage2 libraries with different options for comparison purposes. -

-
-
‘bootstrap-debug-ckovw’
-

Arranges for error messages to be issued if the compiler built on any -stage is run without the option -fcompare-debug. This is -useful to verify the full -fcompare-debug testing coverage. It -must be used along with bootstrap-debug-lean and -bootstrap-debug-lib. -

-
-
‘bootstrap-time’
-

Arranges for the run time of each program started by the GCC driver, -built in any stage, to be logged to time.log, in the top level of -the build tree. -

-
-
- - -

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 recommend first 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 ---with-ecj-jar=…. -

-

Assuming you have already installed a native copy of GCC and configured -your cross compiler, issue the command make, which performs the -following steps: -

- - -

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 -prefix/target/bin. Here is a table of the tools -you should put in this directory: -

-
-
as
-

This should be the cross-assembler. -

-
-
ld
-

This should be the cross-linker. -

-
-
ar
-

This should be the cross-archiver: a program which can manipulate -archive files (linker libraries) in the target machine’s format. -

-
-
ranlib
-

This should be a program to construct a symbol table in an archive file. -

-
- -

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 --host and --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 ---with-sysroot or --with-headers and ---with-libs. Many targets also require “start files” such -as crt0.o and -crtn.o which are linked into each executable. There may be several -alternatives for crt0.o, for use with profiling or other -compilation options. Check your target’s definition of -STARTFILE_SPEC to find out what start files it uses. -

- -

Building in parallel

- -

GNU Make 3.80 and above, which is necessary to build GCC, support -building in parallel. To activate this, you can use ‘make -j 2’ -instead of ‘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. -

- -

Building the Ada compiler

- -

In order to build GNAT, the Ada compiler, you need a working GNAT -compiler (GCC version 4.0 or later). -This includes GNAT tools such as gnatmake and -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. -

-

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 --enable-languages is -used to disable building the Ada front end. -

-

ADA_INCLUDE_PATH and 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 ‘gnatls -v’ lists only one explicit path in each -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 make profiledbootstrap. -

-

When ‘make profiledbootstrap’ is run, it will first build a stage1 -compiler. This compiler is used to build a stageprofile compiler -instrumented to collect execution counts of instruction and branch -probabilities. Then runtime libraries are compiled with profile collected. -Finally a stagefeedback compiler is built using the information collected. -

-

Unlike standard bootstrap, several additional restrictions apply. The -compiler used to build stage1 needs to support a 64-bit integral type. -It is recommended to only use GCC for this. -

-
-

Return to the GCC Installation page -

- - - - - - - -
- - - - - diff -Nur gcc-4.9.3.orig/INSTALL/configure.html gcc-4.9.3/INSTALL/configure.html --- gcc-4.9.3.orig/INSTALL/configure.html 2015-06-26 19:59:18.000000000 +0200 +++ gcc-4.9.3/INSTALL/configure.html 1970-01-01 01:00:00.000000000 +0100 @@ -1,1842 +0,0 @@ - - - - - -Installing GCC - - - - - - - - - - - - - -

Installing GCC

- - - - - - - - - - - - - - - - - - - - - - -

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 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 SVN, 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]
-
- - -

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. -

-
-
--with-pkgversion=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 gcc --version. This suffix does -not replace the default version string, only the ‘GCC’ part. -

-

The default value is ‘GCC’. -

-
-
--with-bugurl=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. -

-
-
- - -

Target specification

- - - - -

Options specification

- -

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=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 -/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. -

-

The following standard autoconf options are supported. Normally you -should not need to use these options. -

-
--exec-prefix=dirname
-

Specify the toplevel installation directory for architecture-dependent -files. The default is prefix. -

-
-
--bindir=dirname
-

Specify the installation directory for the executables called by users -(such as gcc and g++). The default is -exec-prefix/bin. -

-
-
--libdir=dirname
-

Specify the installation directory for object code libraries and -internal data files of GCC. The default is exec-prefix/lib. -

-
-
--libexecdir=dirname
-

Specify the installation directory for internal executables of GCC. -The default is exec-prefix/libexec. -

-
-
--with-slibdir=dirname
-

Specify the installation directory for the shared libgcc library. The -default is libdir. -

-
-
--datarootdir=dirname
-

Specify the root of the directory tree for read-only architecture-independent -data files referenced by GCC. The default is prefix/share. -

-
-
--infodir=dirname
-

Specify the installation directory for documentation in info format. -The default is datarootdir/info. -

-
-
--datadir=dirname
-

Specify the installation directory for some architecture-independent -data files referenced by GCC. The default is datarootdir. -

-
-
--docdir=dirname
-

Specify the installation directory for documentation files (other -than Info) for GCC. The default is datarootdir/doc. -

-
-
--htmldir=dirname
-

Specify the installation directory for HTML documentation files. -The default is docdir. -

-
-
--pdfdir=dirname
-

Specify the installation directory for PDF documentation files. -The default is docdir. -

-
-
--mandir=dirname
-

Specify the installation directory for manual pages. The default is -datarootdir/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
-

Specify -the installation directory for G++ header files. The default depends -on other configuration options, and differs between cross and native -configurations. -

-
-
--with-specs=specs
-

Specify additional command line driver SPECS. -This can be useful if you need to turn on a non-standard feature by -default without modifying the compiler’s source code, for instance ---with-specs=%{!fcommon:%{!fno-common:-fno-common}}. -See “Spec Files” in the main manual -

-
-
- -
-
--program-prefix=prefix
-

GCC supports some transformations of the names of its programs when -installing them. This option prepends prefix to the names of -programs to install in bindir (see above). For example, specifying ---program-prefix=foo- would result in ‘gcc’ -being installed as /usr/local/bin/foo-gcc. -

-
-
--program-suffix=suffix
-

Appends suffix to the names of programs to install in bindir -(see above). For example, specifying --program-suffix=-3.1 -would result in ‘gcc’ being installed as -/usr/local/bin/gcc-3.1. -

-
-
--program-transform-name=pattern
-

Applies the ‘sed’ 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
-

Specify the -installation directory for local include files. The default is -/usr/local. Specify this option if you want the compiler to -search directory dirname/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. -

-
-
--with-native-system-header-dir=dirname
-

Specifies that dirname is the directory that contains native system -header files, rather than /usr/include. This option is most useful -if you are creating a compiler that should be isolated from the system -as much as possible. It is most commonly used with the ---with-sysroot option and will cause GCC to search -dirname inside the system root specified by that option. -

-
-
--enable-shared[=package[,…]]
-

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 -‘libgcc’ (also known as ‘gcc’), ‘libstdc++’ (not -‘libstdc++-v3’), ‘libffi’, ‘zlib’, ‘boehm-gc’, -‘ada’, ‘libada’, ‘libjava’, ‘libgo’, and ‘libobjc’. -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
-

Specify that the host code should be built into position-independent -machine code (with -fPIC), allowing it to be used within shared libraries, -but yielding a slightly slower compiler. -

-

Currently this option is only of use to people developing GCC itself. -

-

Contrast with --enable-shared, which affects target -libraries. -

-
-
--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 --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=pathname or ---with-build-time-tools=pathname. -

-

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=pathname
-

Specify that the compiler should use the assembler pointed to by -pathname, rather than the one found by the standard rules to find -an assembler, which are: -

- -

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
-

Same as --with-gnu-as -but for the linker. -

-
-
--with-ld=pathname
-

Same as --with-as -but for the linker. -

-
-
--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 --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. -

-
-
--with-tls=dialect
-

Specify the default TLS dialect, for systems were there is a choice. -For ARM targets, possible values for dialect are gnu or -gnu2, which select between the original GNU dialect and the GNU TLS -descriptor-based dialect. -

-
-
--enable-multiarch
-

Specify whether to enable or disable multiarch support. The default is -to check for glibc start files in a multiarch location, and enable it -if the files are found. The auto detection is enabled for native builds, -and for cross builds configured with --with-sysroot, and without ---with-native-system-header-dir. -More documentation about multiarch can be found at -http://wiki.debian.org/Multiarch. -

-
-
--enable-vtable-verify
-

Specify whether to enable or disable the vtable verification feature. -Enabling this feature causes libstdc++ to be built with its virtual calls -in verifiable mode. This means that, when linked with libvtv, every -virtual call in libstdc++ will verify the vtable pointer through which the -call will be made before actually making the call. If not linked with libvtv, -the verifier will call stub functions (in libstdc++ itself) and do nothing. -If vtable verification is disabled, then libstdc++ is not built with its -virtual calls in verifiable mode at all. However the libvtv library will -still be built (see --disable-libvtv to turn off building libvtv). ---disable-vtable-verify is the default. -

-
-
--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., --disable-softfloat): -

-
arm-*-*
-

fpu, 26bit, underscore, interwork, biendian, nofmult. -

-
-
m68*-*-*
-

softfloat, m68881, m68000, m68020. -

-
-
mips*-*-*
-

single-float, biendian, softfloat. -

-
-
powerpc*-*-*, rs6000*-*-*
-

aix64, pthread, softfloat, powercpu, powerpccpu, powerpcos, biendian, -sysv, aix. -

-
-
- -
-
--with-multilib-list=list
-
--without-multilib-list
-

Specify what multilibs to build. -Currently only implemented for sh*-*-* and x86-64-*-linux*. -

-
-
sh*-*-*
-

list is a comma separated list of CPU names. These must be of the -form 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*
-

list is a comma separated list of 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-endian=endians
-

Specify what endians to use. -Currently only implemented for sh*-*-*. -

-

endians may be one of the following: -

-
big
-

Use big endian exclusively. -

-
little
-

Use little endian exclusively. -

-
big,little
-

Use big endian by default. Provide a multilib for little endian. -

-
little,big
-

Use little endian by default. Provide a multilib for big endian. -

-
- -
-
--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, --enable-threads is an -alias for --enable-threads=single. -

-
-
--disable-threads
-

Specify that threading support should be disabled for the system. -This is an alias for --enable-threads=single. -

-
-
--enable-threads=lib
-

Specify that -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 lib are: -

-
-
aix
-

AIX thread support. -

-
dce
-

DCE thread support. -

-
lynx
-

LynxOS thread support. -

-
mipssde
-

MIPS SDE thread support. -

-
no
-

This is an alias for ‘single’. -

-
posix
-

Generic POSIX/Unix98 thread support. -

-
rtems
-

RTEMS thread support. -

-
single
-

Disable thread support, should work for all platforms. -

-
tpf
-

TPF thread support. -

-
vxworks
-

VxWorks thread support. -

-
win32
-

Microsoft Win32 API thread support. -

-
- -
-
--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 ---enable-tls or --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. -

-
-
--disable-tls
-

Specify that the target does not support TLS. -This is an alias for --enable-tls=no. -

-
-
--with-cpu=cpu
-
--with-cpu-32=cpu
-
--with-cpu-64=cpu
-

Specify which cpu variant the compiler should generate code for by default. -cpu will be used as the default value of the -mcpu= switch. -This option is only supported on some targets, including ARC, ARM, i386, M68k, -PowerPC, and SPARC. It is mandatory for ARC. The --with-cpu-32 and ---with-cpu-64 options specify separate default CPUs for -32-bit and 64-bit modes; these options are only supported for i386, -x86-64 and PowerPC. -

-
-
--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
-

These configure options provide default values for the -mschedule=, --march=, -mtune=, -mabi=, and -mfpu= -options and for -mhard-float or -msoft-float. As with ---with-cpu, which switches will be accepted and acceptable values -of the arguments depend on the target. -

-
-
--with-mode=mode
-

Specify if the compiler should default to -marm or -mthumb. -This option is only supported on ARM targets. -

-
-
--with-stack-offset=num
-

This option sets the default for the -mstack-offset=num option, -and will thus generally also control the setting of this option for -libraries. This option is only supported on Epiphany targets. -

-
-
--with-fpmath=isa
-

This options sets -mfpmath=sse by default and specifies the default -ISA for floating-point arithmetics. You can select either ‘sse’ which -enables -msse2 or ‘avx’ which enables -mavx by default. -This option is only supported on i386 and x86-64 targets. -

-
-
--with-nan=encoding
-

On MIPS targets, set the default encoding convention to use for the -special not-a-number (NaN) IEEE 754 floating-point data. The -possibilities for encoding are: -

-
legacy
-

Use the legacy encoding, as with the -mnan=legacy command-line -option. -

-
2008
-

Use the 754-2008 encoding, as with the -mnan=2008 command-line -option. -

-
-

To use this configuration option you must have an assembler version -installed that supports the -mnan= command-line option too. -In the absence of this configuration option the default convention is -the legacy encoding, as when neither of the -mnan=2008 and --mnan=legacy command-line options has been used. -

-
-
--with-divide=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 type are: -

-
traps
-

Division by zero checks use conditional traps (this is the default on -systems that support conditional traps). -

-
breaks
-

Division by zero checks use the break instruction. -

-
- - -
-
--with-llsc
-

On MIPS targets, make -mllsc the default when no --mno-llsc option is passed. This is the default for -Linux-based targets, as the kernel will emulate them if the ISA does -not provide them. -

-
-
--without-llsc
-

On MIPS targets, make -mno-llsc the default when no --mllsc option is passed. -

-
-
--with-synci
-

On MIPS targets, make -msynci the default when no --mno-synci option is passed. -

-
-
--without-synci
-

On MIPS targets, make -mno-synci the default when no --msynci option is passed. This is the default. -

-
-
--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. -

-
-
--enable-__cxa_atexit
-

De