From 7ed4d2a409cb24e7beef850c6b90e47f0f6b71d2 Mon Sep 17 00:00:00 2001 From: Waldemar Brodkorb Date: Sat, 9 Apr 2016 12:48:08 +0200 Subject: add support for nds32 architecture Verified on a FPGA board sponsored by Andes Technology. Signed-off-by: Waldemar Brodkorb --- toolchain/gcc/Makefile | 4 + toolchain/gcc/patches/4.9.3/gcc.nds32 | 383894 +++++++++++++++++++++++++++++++ 2 files changed, 383898 insertions(+) create mode 100644 toolchain/gcc/patches/4.9.3/gcc.nds32 (limited to 'toolchain/gcc') diff --git a/toolchain/gcc/Makefile b/toolchain/gcc/Makefile index 51c12d0fd..78f4a025b 100644 --- a/toolchain/gcc/Makefile +++ b/toolchain/gcc/Makefile @@ -123,6 +123,10 @@ ifeq ($(ADK_TARGET_CPU_CF),y) GCC_CONFOPTS+= --enable-multilib --with-arch=cf endif +ifeq ($(ADK_TARGET_ARCH_NDS32),y) +GCC_CONFOPTS+= --with-arch=v3 +endif + ifeq ($(ADK_TARGET_ARCH_M68K)$(ADK_TARGET_ARCH_X86_64)$(ADK_TARGET_ARCH_X86),) GCC_FINAL_CONFOPTS+= --disable-biarch --disable-multilib endif diff --git a/toolchain/gcc/patches/4.9.3/gcc.nds32 b/toolchain/gcc/patches/4.9.3/gcc.nds32 new file mode 100644 index 000000000..0335a98b7 --- /dev/null +++ b/toolchain/gcc/patches/4.9.3/gcc.nds32 @@ -0,0 +1,383894 @@ +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. +-

+-
    +-
  • ‘hppa1.0-any-any’ +-
  • ‘hppa1.1-any-any’ +-
  • ‘sparc-sun-solaris2.any’ +-
  • ‘sparc64-any-solaris2.any’ +-
+- +-
+-
--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: +-

    +-
  • Unless GCC is being built with a cross compiler, check the +-libexec/gcc/target/version directory. +-libexec defaults to exec-prefix/libexec; +-exec-prefix defaults to prefix, which +-defaults to /usr/local unless overridden by the +---prefix=pathname switch described above. target +-is the target system triple, such as ‘sparc-sun-solaris2.7’, and +-version denotes the GCC version, such as 3.0. +- +-
  • If the target system is the same that you are building on, check +-operating system specific directories (e.g. /usr/ccs/bin on +-Sun Solaris 2). +- +-
  • Check in the PATH for a tool whose name is prefixed by the +-target system triple. +- +-
  • Check in the PATH for a tool whose name is not prefixed by the +-target system triple, if the host and target system triple are +-the same (in other words, we use a host tool if it can be used for +-the target as well). +-
+- +-

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