This matrix is for people who wish to compile and run their code with arbitrary GCC releases and using the appropriate matching binutils, glibc and numactl, going back to 4.1.2. It allows the correct selection of glibc, binutils and numactl, for a given GCC release.
For a given GCC,
- look backwards in time for binutils and libmpfr (GCC uses these tools/libraries, so the assumption is that the latest version existant at the time of the GCC release is in use)
- look forwards in time for glibc and numactrl (any given library could only be compiled with a compiler which already existed at the time that library was released)
Enter The Matrix
|Jun 27||4.6.1, 4.3.6||2.21.1|
|Aug 16||1.0.1, 1.0|
|Jul 31||2.5.1, 2.6.1|
1. Yes, 2.16.0, not 2.16 - I have no idea why.
2. Yes, 4.2, not 4.2.0
Turn Back All Ye Who Enter Here
Building GCC from scratch is a nightmare. If you Google for help, you will find the answer given to everyone who is asking for help with this is to boot up an old distro. There's a reason for that; it's actually just about impossible to build GCC. I have spent now about thirty man-hours trying to build a (just one!) GCC and I have this moment now finally succeeded. Be aware also the problems vary by which version of GCC you wish to build.
The first major note is to treat all GCC documentation about building with distrust. Some of what is written is simply wrong. Some is completely misleading. Some is valid only for recent versions of GCC. Some things are simply omitted. The GCC documentation will if you take it at face value lead you badly astray and it will take you a long time to actually work out the truth.
The next major note is to remember that open source software is often broken out of the box, and comes without documentation. This particularly applies to binutils. For example, all releases of binutils come with warnings set to errors, and all have warnings. NONE of them build, not even the latest version. When you disable warnings as errors, still releases 2.17, 2.18 and 2.19 are broken. Release 2.20 seems to be the first release which actually builds.
Be aware there are also subtle problems; for example, gnumake changed between version 3.80 and 3.81 such that it added a new build-in rule for the suffix .m, which probably breaks the build for GCC 4.1.2 (as this existed before 3.81 came out and has .m files which are yacc files rather than m4 files).
Also remember not to trust the GCC build itself. If a dependency is placed in the wrong location, GCC will not complain, but will configure and build it, and only THEN when it comes to try use the dependency will it complain. Additionally, as with binutils, it looks like some of the GCC builds are just broken.
Technical Notes on Building GCC
When building a compiler, to do the job properly, the compiler is first built with the compiler installed on the local system, and then that compiler is in turn used to build the compiler code a second time; so we end up with a compiler compiled by itself.
GCC does this automatically when it builds.
Additionally, however, GCC has some external dependencies. First, on tools like ar and ld. These come from a package known as bintools. You can download bintools and if it is placed in the GCC source directory, GCC will detect it and compile it; if you do not download it, GCC will use the tools installed on your system (which may be much more modern than the compiler you're trying to build, and you might well want for consistency to be using the versions contemporary with the GCC you're building).
Secondly, there are three libraries which GCC depends upon, although it's not quite clear which versions of GCC depende on what; I think up to (but not including) 4.3.0 only bintools, after that for a while it's libgmp and/or libmpc/libmprf, and then eventually it's all three.
Apparently GCC is quite sensitive to the versioning of these libraries, so simply having the development packages for them installed on your local system may not work. Fortunately, however, as with binutils, downloading these libraries and placing them into the GCC source directory causes GCC to compile them.
Note that with the libraries, but not with bintools, their directory is moved into the root of the GCC source tree (and renamed, loosing the version part of the name). However, bintools is fucked up, and although this is in fact what has to be done, it does not work as you would expect, because GCC ends up looking in the wrong place for the binaries produced by bintools. The solution to this is the manually make softlinks from the place where GCC looks to the place where the binaries are. Yes, I know this is absolutely nuts and you're questioning my sanity - but as you will discover, it really is so.
(You'll begin to understand more when I tell you all versions of binutils have warnings-as-errors, and all versions have warnings, so NO versions actually compile out of the box).
Vital Read Me Or The Build Will Fail Notes On Builing GCC
1. With older versions of GCC (I think up to but not including 4.6.0, but don't quote me on that) the documentation included does not work with modern version of texinfo. This breaks the build. The only way I've found to address this is to uninstall texinfo.
2. Version 4.1.2 of GCC uses gnumake 3.80, as 3.81 was not yet released. 3.81 adds a new built-in rule, for the suffix .m, which I have read breaks the gprof makefile in binutils.
3. binutils 2.17 seems to have a completely bizarre dependency on Objective C. Compiling GCC with Objective-C built in didn't help, so I had to install it on the host.
4. ALL versions of binutils must be configured with --disable-werror or they will fail to compile. This is because all versions having warnings. If you pass --disable-werror to the GCC configure, it will propagate this down to the binutils configure.
0. Change directory to /tmp. You can build anywhere, of course, but I'm using /tmp.
1. Download GCC 4.4.3, uncompress and untar - this will give you /tmp/gcc-4.4.3, which is what we want.
wget ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-4.4.4/gcc-4.4.3.tar.bz2 -O /tmp/gcc-4.4.3.tar.bz2 bzip2 -d gcc-4.4.3.tar.bz2 tar -xf gcc-4.4.3.tar
2. Download GMP 5.0.0, uncompress, untar, move and rename directory to /tmp/gcc-4.4.3/gmp. GMP I think is needed by libmpfr. GCC will automatically use the headers in the gmp directory.
? ? ?
3. Download binutils 2.20, unbzip2, untar, move and rename directory to /tmp/gcc-4.4.3/binutils
wget ftp://sourceware.org/pub/binutils/releases/binutils-2.20.tar.bz2 -O /tmp/binutils-2.20.tar.bz2 bzip2 -d binutils-2.20.tar.bz2 tar -xf binutils-2.20.tar mv binutils-2.20 gcc-4.4.3/binutils
4. Download libmpfr 2.4.2, unbzip2, untar, move and rename directory to /tmp/gcc-4.4.3/mpfr
wget ftp://ftp.gnu.org/gnu/mpfr/mpfr-2.4.2.tar.bz2 -O /tmp/mpfr-2.4.2.tar.bz2 bzip2 -d mpfr-2.4.2.tar.bz2 tar -xf mpfr-2.4.2.tar mv mpfr-2.4.2 gcc-4.4.3/mpfr
5. Set an environment variable LIBRARY_PATH to /usr/lib/x86_64-linux-gnu (use export with bash, instead of setenv)
6. Make a new directory, /tmp/gccbuild, and change to that directory
7. now issue the configure command; you will need to vary the arguments according to your exact needs, but note that --disable-werror is mandatory, or binutils will break the build with its warnings; this will give you a GCC binary named gcc-4.4.3
/tmp/gcc-4.4.3/configure --disable-multilib --enable-threads=posix --enable-languages=c --disable-werror --program-suffix=-4.4.3 --prefix=/usr/local/gcc/gcc-4.4.3
8. issue the make command (use -j and run one make per logical processor to speed things up, you'll need it)
9. this first make will run for quite a while and then fail, claiming it cannot find ar; you now need to make softlinks, because binutils is in the wrong place (but you can't put in the right place because of conflicts with the GCC directory structure)
10. change directory to /tmp/gccbuild/binutils and issue the following commands;
ln -s binutils/ar ln -s binutils/ranlib ln -s binutils/nm-new ln -s gas/ld-new ln -s gas/as-new
11. now change back to /tmp/gccbuild and run make again
12. make will fail again, this time complaining about no debug info found; what seems to have happened is one of the scripts it creates is created broken, we fix it now
13. edit the file /tmp/gccbuild/gcc/nm, go to line 24 and you should see this;
change this to
14. run make again and now, finally, GCC should successfully build
15. you can now run make install (you'll need to run this as root if the destination directories are owned by root, as they are with the example configure command used here)