Note that this article is meant to be included into the GCC Cross-Compiler and Building GCC as they share this common section.

The GNU Compiler Collection is an advanced piece of software with dependencies. You need to install certain dependencies in order to build gcc. You need to install GNU make, GNU bison, flex, and of course an existing system compiler you wish to replace. In addition, you also need the packages GNU GMP, GNU MPFR, and MPC that are used by GCC for floating point support.

You need a host system with a working GCC installation, and enough memory as well as hard drive space. How much qualifies as "enough" is depending on the versions of the software involved, but GCC is a big piece of software, so don't be surprised when 128 or 256 MByte are not sufficient.

In short you need the following that you can install manually or through package management:

  • An Unix-like environment (Windows users)
  • GCC (existing release you wish to replace)
  • G++ (if building a version of GCC >= 4.8.0)
  • GNU Make
  • GNU Bison
  • Flex
  • GNU libiconv (Mac OS X users)
  • GNU GMP
  • GNU MPFR
  • GNU MPC
  • ISL (optional)
  • CLooG (optional)

Downloading the Source Code

You can download the desired binutils release by visiting the binutils website or directly accessing the GNU main ftp mirror.

You can download the desired gcc release by visiting the GCC website or directly accessing the GNU main ftp mirror.

In addition, to build GCC you need to have installed GNU GMP, GNU MPFR, GNU MPC and the ISL library. Additionally, Mac OS X users need a replacement libiconv because the system libiconv is seriously out of date. You may already have these libraries and the development files installed, but this tutorial builds them as part of GCC. If you don't need this, simply don't build them as part of GCC. Note that not all GMP, MPFR and MPC combinations are compatible with a given GCC release.

You can download GNU GMP from its website. (libgmp3-dev on apt-based systems, dev-libs/gmp on Gentoo, gmp-devel on Fedora, libgmp-devel on Cygwin)

You can download GNU MPFR from its website. (libmpfr-dev on apt-based systems, dev-libs/mpfr on Gentoo, mpfr-devel on Fedora, libmpfr-devel on Cygwin)

You can download ISL from its website (optional). (libisl-dev on apt-based systems)

You can download ClooG from its website (optional). (libcloog-isl-dev on apt-based systems)

You can download GNU MPC from its website. (libmpc-dev on apt-based systems, dev-libs/mpc on Gentoo, libmpc-devel on Fedora, libmpc-devel on Cygwin)

Mac OS X users can download the latest libiconv release by visiting the libiconv website or directly accessing the GNU main ftp mirror.

In my experience, texinfo seems to be a required package for building some of the binutils (in particular, "as"). The cross-compiler may still build, but you might get weird errors when the compiler calls "as" and gets the system one instead. Even worse, you might not. The same problem was also discovered here.

Download the needed source code into a suitable directory such as $HOME/src.

Note: The versioning scheme used is that each fullstop separates a full number, i.e. binutils 2.20.0 is newer than 2.9.0. This may be confusing, if you have not encountered this (quite common) versioning scheme yet, when looking at an alphanumerically sorted list of tarballs: The file at the bottom of the list is not the latest version! An easy way of getting the latest version is to sort by the last modified date and scrolling to the bottom.

Note: Version 5.x (or later) of texinfo is known to be incompatible with the current binutils 2.23.2 release (and older). You can check your current version using makeinfo --version. If your version is too new and you encounter problems during the build, you will need to either use binutils 2.24 release (or newer) or install an older version of texinfo - perhaps through building from source - and add it to your PATH prior and during the binutils build.

Linux Users

Your distribution may ship its own patched GCC and Binutils that is customized to work on your particular Linux distribution. You may not be able to build a functional system compiler using the upstream sources you downloaded above. In that case, try a newer GCC release or get the patched source code. For instance, some GCC releases are known to not understand the new Debian multiarch directory structure. However, if the compiler we are about to build is a cross-compiler targetting another operating system (such as your new one), then this is much less a worry.

Mac OS X Users

When compiling GCC 4.3 or higher on OS X 10.4 and 10.5, you may get unresolved symbol errors related to libiconv. This is because the version shipped with OS X is seriously out of date. Install a new version (compile it yourself or use macports) and add --with-libiconv-prefix=/opt/local (or /usr/local if you compiled it yourself) to GCC's ./configure line. Alternatively you may place the libiconv source as gcc-x.y.z/libiconv and it will be compiled as part of the GCC compilation process. (This trick also works for mpfr, gmp, and mpc).

The makefiles of binutils and GCC use the $(CC) variable to invoke the compiler. On Mac OS, this resolves to gcc by default, which is actually not the "real thing", but llvm-gcc. That wouldn't be so bad, but llvm-gcc is not able to compile the GCC sources into a functional binary. (Bugs have been reported, but that doesn't help you here and now.)

MacOS does have a "real" GCC installed, too. You just have to tell make to use it instead of llvm-gcc:

# This is only necessary for MacOS users.
export CC=/usr/bin/gcc-4.2
export CXX=/usr/bin/g++-4.2
export CPP=/usr/bin/cpp-4.2
export LD=/usr/bin/gcc-4.2

You might want to unset these exports once you compiled and installed the cross compiler, as it might confuse other builds. Do not make these permanent!

Note for Lion users: If you're on Lion (or above) chances are that you don't have the "real" gcc since Apple removed it from the Xcode package, but you can still install it. You can do it via Homebrew or by compiling from source, both are perfectly described on a StackExchange answer.

Note for Maverick users: You can build binutil-2.24 and gcc-4.8.3 (possible other version) with xcode 5.1.1. Note that building gcc with llvm is not officially supported and may cause interesting bugs, if you are willing to take this risk and save time building host-gcc just to compile a cross-gcc, follow this. Install GMP, MPFR, MPC with macport.

sudo port install gmp mpfr libmpc
../binutils-2.24/configure --prefix=$PREFIX \
--target=$TARGET \
--enable-interwork --enable-multilib \
--disable-nls --disable-werror
../gcc-4.8.3/configure --prefix=$PREFIX \
--target=$TARGET \
--disable-nls \
--enable-language=c,c++ --without-headers \
--enable-interwork --enable-multilib \
--with-gmp=/usr --with-mpc=/opt/local --with-mpfr=/opt/local
  • Note that there is issue with port's gmp, we use the version from mac os x from /usr instead.

Windows Users

Windows users need to set up a Unix-like enviroment such as MinGW or Cygwin. It may well be worth looking into systems such as Linux and see if they fit your needs, as you commonly use a lot of Unix-like tools in operating systems development and this is much easier from a Unix-like operating system. If you have just installed the basic Cygwin package, you have to run the setup.exe again and install the following packages: GCC, Make, Flex, Bison, and Diffutils.

MinGW + MSYS is an option, and as it addresses the native Windows API instead of a POSIX emulation layer, results in a slightly faster toolchain. Some software packages will not build properly under MSYS as they were not designed for use with Windows. As far as this tutorial is concerned, everything that applies to Cygwin also applies to MSYS unless otherwise specified. Make sure you install the C and C++ compilers, and the MSYS Basic System.

Cygwin note: Cygwin includes your Windows %PATH% in its bash $PATH. If you were using DJGPP before, this could result in confusion as e.g. calling gcc on the Cygwin bash command line would still call the DJGPP compiler. After uninstalling DJGPP, you should delete the DJGPP environment variable and clear the C:\djgpp entry (or wherever you installed it) from your %PATH%. Likewise, it might be a bad idea to mix build environments in your system PATH variable.

MinGW note: Some MinGW-specific information on building a cross-toolchain can be found on the hosted cross-compiler how-to page on the MinGW homepage.