How to update your GCC in Ubuntu

Hey guys, this is my first blog on CNBLOGS. 

　　In this Blog, I want to talk about "How to update your GCC in Ubuntu". There are many ways you could update your gcc version. But, updating your gcc by instruction--"apt" or Update Manager could not get the latest version of gcc. You must wait the Ubuntu guys update resources. 

　　Now, I will introduce the normal way of updating gcc to you. 

　　The installation procedure itself is broken into five steps.

　　1.Prerequisites

　　2.Downloading the source

　　3.Configuration

　　4.Building

　　5.Final install

 

　　In first step, there are many tools and packages you must install before you build GCC. 

　　ISO C90 compiler

Necessary to bootstrap GCC, although versions of GCC prior to 3.4 also allow bootstrapping with a traditional (K&R) C compiler.

To build all languages in a cross-compiler or other configuration where 3-stage bootstrap is not performed, you need to start with an existing GCC binary (version 2.95 or later) because source code for language frontends other than C might use GCC extensions. 

　　GNAT

In order to build the Ada compiler (GNAT) you must already have GNAT installed because portions of the Ada frontend are written in Ada (with GNAT extensions.) Refer to the Ada installation instructions for more specific information. 

　　A “working” POSIX compatible shell, or GNU bash

Necessary when running configure because some /bin/sh shells have bugs and may crash when configuring the target libraries. In other cases, /bin/sh or ksh have disastrous corner-case performance problems. This can cause target configure runs to literally take days to complete in some cases.

So on some platforms /bin/ksh is sufficient, on others it isn't. See the host/target specific instructions for your platform, or use bash to be sure. Then set CONFIG_SHELL in your environment to your “good” shell prior to running configure/make.

zsh is not a fully compliant POSIX shell and will not work when configuring GCC. 

　　A POSIX or SVR4 awk

Necessary for creating some of the generated source files for GCC. If in doubt, use a recent GNU awk version, as some of the older ones are broken. GNU awk version 3.1.5 is known to work. 

　　GNU binutils

Necessary in some circumstances, optional in others. See the host/target specific instructions for your platform for the exact requirements. 

　　gzip version 1.2.4 (or later) or 　　bzip2 version 1.0.2 (or later)

Necessary to uncompress GCC tar files when source code is obtained via FTP mirror sites. 

　　GNU make version 3.80 (or later)

You must have GNU make installed to build GCC. 

　　GNU tar version 1.14 (or later)

Necessary (only on some platforms) to untar the source code. Many systems' tar programs will also work, only try GNU tar if you have problems. 

　　Perl version 5.6.1 (or later)

Necessary when targetting Darwin, building ‘libstdc++’, and not using --disable-symvers. Necessary when targetting Solaris 2 with Sun ld and not using --disable-symvers. The bundled perl in Solaris 8 and up works.

Necessary when regenerating Makefile dependencies in libiberty. Necessary when regeneratinglibiberty/functions.texi. Necessary when generating manpages from Texinfo manuals. Used by various scripts to generate some files included in SVN (mainly Unicode-related and rarely changing) from source tables. 

　　jar, or InfoZIP (zip and unzip)

Necessary to build libgcj, the GCJ runtime.

　　Several support libraries are necessary to build GCC, some are required, others optional. While any sufficiently new version of required tools usually work, library requirements are generally 　　stricter. Newer versions may work in some cases, but it's safer to use the exact versions documented. We appreciate bug reports about problems with newer versions, though. If your OS 　　　vendor provides packages for the support libraries then using those packages may be the simplest way to install the libraries.

　　GNU Multiple Precision Library (GMP) version 4.3.2 (or later)

Necessary to build GCC. If a GMP source distribution is found in a subdirectory of your GCC sources namedgmp, it will be built together with GCC. Alternatively, if GMP is already installed but it is not in your library search path, you will have to configure with the --with-gmp configure option. See also --with-gmp-lib and --with-gmp-include. 

　　MPFR Library version 2.4.2 (or later)

Necessary to build GCC. It can be downloaded from http://www.mpfr.org/. If an MPFR source distribution is found in a subdirectory of your GCC sources named mpfr, it will be built together with GCC. Alternatively, if MPFR is already installed but it is not in your default library search path, the --with-mpfr configure option should be used. See also --with-mpfr-lib and --with-mpfr-include. 

　　MPC Library version 0.8.1 (or later)

Necessary to build GCC. It can be downloaded from http://www.multiprecision.org/. If an MPC source distribution is found in a subdirectory of your GCC sources named mpc, it will be built together with GCC. Alternatively, if MPC is already installed but it is not in your default library search path, the --with-mpc configure option should be used. See also --with-mpc-lib and --with-mpc-include. 

　　Parma Polyhedra Library (PPL) version 0.11

Necessary to build GCC with the Graphite loop optimizations. It can be downloaded fromhttp://www.cs.unipr.it/ppl/Download/.

The --with-ppl configure option should be used if PPL is not installed in your default library search path. 

　　CLooG-PPL version 0.15 or CLooG 0.16

Necessary to build GCC with the Graphite loop optimizations. There are two versions available. CLooG-PPL 0.15 as well as CLooG 0.16. The former is the default right now. It can be downloaded fromftp://gcc.gnu.org/pub/gcc/infrastructure/ as cloog-ppl-0.15.tar.gz.

CLooG 0.16 support is still in testing stage, but will be the default in future GCC releases. It is also available at ftp://gcc.gnu.org/pub/gcc/infrastructure/ as cloog-0.16.1.tar.gz. To use it add the additional configure option --enable-cloog-backend=isl. Even if CLooG 0.16 does not use PPL, PPL is still required for Graphite.

In both cases --with-cloog configure option should be used if CLooG is not installed in your default library search path.

 

　　

　　Second, you could download the gcc 4.7.0 version from http://linux.softpedia.com/get/Programming/Compilers/GCC-641.shtml. 

　　After that you could configure it. Like most GNU software, GCC must be configured before it can be built. You need srcdir to refer to the toplevel source directory for GCC and bjdir to refer to the toplevel build/object directory.

　　First, GCC be built into a separate directory from the sources which does not reside within the source tree. This is how GCC Team 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]


After you configured GCC, you could build the compiler and runtime libraries.

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 usescontrib/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 totime.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 commandmake, 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-headersand --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 astageprofile 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.

Now you can install it with
"cd objdir && make install"

You can install stripped programs and libraries with
"make install-strip"

OK, after you finished these steps, your new GCC could be installed.

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Chad
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　4-23-2012
References:
The ReadMe text "Installation of GCC" from GNU.ORG;
Aking1012's answer at http://superuser.com/questions/310809/how-can-i-update-gcc-to-the-latest-version-in-ubuntu-10-04

转载于:https://www.cnblogs.com/ChadZhan/archive/2012/04/23/2465988.html