From 554fd8c5195424bdbcabf5de30fdc183aba391bd Mon Sep 17 00:00:00 2001 From: upstream source tree Date: Sun, 15 Mar 2015 20:14:05 -0400 Subject: obtained gcc-4.6.4.tar.bz2 from upstream website; verified gcc-4.6.4.tar.bz2.sig; imported gcc-4.6.4 source tree from verified upstream tarball. downloading a git-generated archive based on the 'upstream' tag should provide you with a source tree that is binary identical to the one extracted from the above tarball. if you have obtained the source via the command 'git clone', however, do note that line-endings of files in your working directory might differ from line-endings of the respective files in the upstream repository. --- INSTALL/build.html | 380 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 380 insertions(+) create mode 100644 INSTALL/build.html (limited to 'INSTALL/build.html') diff --git a/INSTALL/build.html b/INSTALL/build.html new file mode 100644 index 000000000..644900fd6 --- /dev/null +++ b/INSTALL/build.html @@ -0,0 +1,380 @@ + + +Installing GCC: Building + + + + + + + + + + +

Installing GCC: Building

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

Build tools necessary to build the compiler. + +
Perform a 3-stage bootstrap of the compiler. This includes building +three times the target tools for use by the compiler such as binutils +(bfd, binutils, gas, gprof, ld, and opcodes) if they have been +individually linked or moved into the top level GCC source tree before +configuring. + +
Perform a comparison test of the stage2 and stage3 compilers. + +
Build runtime libraries using the stage3 compiler from the previous step. + +

+ +

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

Build host tools necessary to build the compiler. + +
Build target tools for use by the compiler such as binutils (bfd, +binutils, gas, gprof, ld, and opcodes) +if they have been individually linked or moved into the top level GCC source +tree before configuring. + +
Build the compiler (single stage only). + +
Build runtime libraries using the compiler from the previous step. +

+ +

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. Also parallel make is currently +not supported since collisions in profile collecting may occur. + +

Return to the GCC Installation page + + + + + + + + + + + -- cgit v1.2.3