Build from source an official release of Linaro toolchain

Why would anybody want to do this?

• To add a few custom modifications of your own to an officially released toolchain.
• You encounter a possible bug with the toolchain and would like to fix it on your own instead of waiting for a fix from the developers Linaro community (no offense to them of course).
• If you “feel” that a toolchain built on the very machine that you are going to use it on would somehow be more stable and/or efficient than a toolchain that was built on some other machine that was slightly different from the one that you have (difference in installed Linux distro for instance).

Based on the official Linaro guide

The official guide to building a Linaro toolchain from source is currently provided by the Linaro team at the webpage https://wiki.linaro.org/ABE. The build instructions provided below are actually a derivative of whatever has already been described in the said wiki. In case you want to delve deeper into the subject please refer to the Linaro wiki.

System requirements

It takes my workstation about 40 minutes to rebuild a Linaro toolchain (official release). But that’s with all the necessary source packages pre-downloaded from a previous build. My workstation configuration:

• An 64-bit Intel(R) Core(TM) i5-4570S CPU @ 2.90GHz quad-core machine.
• It’s running Ubuntu 14.04.5 LTS 64-bit OS.

I also had to ensure that necessary packages were installed. This I did by simply running the command:

$ sudo apt-get install flex bison autogen automake autoconf libtool texinfo gawk libncurses5-dev libpython2.7-dev gcc-multilib g++-multilib dejagnu lsb zlib1g-dev

The above list of packages is not an exhaustive one. If during the rest of the build process, the system indicates that a particular package is missing and needs to be installed, you can use the same “sudo apt-get install … ” command to do so.

Download the officially released pre-built toolchain

In this tutorial we will focus on building a pre-built, officially released, Linaro 16.02 toolchain from source. To be more specific, we will build the source for gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf.tar.xz. Before we start building its source, we first want to know the components that went into building it. That information is contained in the pre-built toolchain archive as a “manifest” file. So,

• Download the pre-built toolchain archive.

$ wget https://releases.linaro.org/components/toolchain/binaries/5.3-2016.02/arm-linux-gnueabihf/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf.tar.xz

• Extract it.

$ tar -xJf gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf.tar.xz

• Examine the manifest file for the toolchain.

$ less gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf/gcc-linaro-5.3-2016.02-manifest.txt

Getting the right ABE

The first thing we need to look for is the exact version of ABE (Click to find out What is ABE? Why it exists?) that was used to build the toolchain. I faced trouble if I simply used the latest version of ABE for the build. In the current case we find the following two lines in the “manifest” file:

abe_revision=f03bface90aa7f9faff1cd88bf8e82399b6c0af2
abe_version="abe.git@f03bface90aa7f9faff1cd88bf8e82399b6c0af2"

To get that exact version do the following:

$ git clone https://git.linaro.org/toolchain/abe.git
$ cd abe/
$ git checkout f03bface90aa7f9faff1cd88bf8e82399b6c0af2

Configure and build

We will need a “workspace” directory outside the abe/ directory that you just cloned. I am going to create it with the name “workspace”. Any name is fine. All the action during the build is going to take place from within this directory.

# Step out of the abe/ directory
$ cd ..
# Create your workspace directory
$ mkdir workspace
$ cd workspace/

Configure

$ ../abe/configure --with-fileserver=148.251.136.42 --with-remote-snapshots=/snapshots-ref

The above command is the the standard one. It will create the snapshots/ and the builds/ directory. The sources will get downloaded into the snapshots/ directory. The compilation will take place within the builds/ directory. See the ABE wiki for details on the ABE command options.

Build

Referring back to the downloaded manifest file, and a few build iterations, I have learnt that I needed to explicitly specify the component versions for at least three of the toolchain components to build a toolchain that is the closest match to the officially released, pre-built toolchain. These components and their versions as per the “manifest” file are:

GCC

# GCC
gcc_branch=gcc-linaro-5.3-2016.02.tar.xz

Binutils

# Binutils
binutils_branch=binutils-gdb.git/linaro_binutils-2_25-branch
binutils_revision=ef90a4718f535cbe6345b4e7168baea7b1972abf
binutils_version=binutils-gdb.git@ef90a4718f535cbe6345b4e7168baea7b1972abf

Glibc

glibc_version=glibc.git~release/2.21/master
glibc_revision=16d0a0ce7613552301786bf05d7eba8784b5732c

Using this information from the downloaded “manifest”, the ABE command to build the toolchain turns out to be:

$ ../abe/abe.sh --target arm-linux-gnueabihf gcc=gcc-linaro-5.3-2016.02.tar.xz binutils=binutils-gdb.git@ef90a4718f535cbe6345b4e7168baea7b1972abf glibc=glibc.git@16d0a0ce7613552301786bf05d7eba8784b5732c --release 2016.02 --tarball --build all

When the build gets successfully completed, the resulting archive of the built, distributable binaries will be available in the snapshots/ directory. You can then compare the “manifest” file within this resulting archive to the one you had downloaded and referred to during the above build process.

Points to be noted

1. Going back to the above ABE command that built the toolchain, if we leave out specifying the component versions of the Binutils and Glibc, the latest versions of those from their branches (mostly the same release branch) will automatically be fetched during the build. This may be a desirable thing as the latest versions will have fixes for bugs that were discovered in the original pre-built toolchain from Linaro.
2. In case you do not want ABE utility to check and update (or overwrite) the already downloaded code from the source server URL, use the “–disable update” option for ABE utility. This might help you when you are customizing the final toolchain by editing source code in the snapshots/ directory.
3. The ABE utility has a “–manifest ” command option. This is supposed to source the manifest file and override the default configuration. This is used to reproduce an identical toolchain build from manifest files generated by a previous build. Now I tried using this option to simplify the build procedure. However, I faced build failures. And no matter what additional command options I supplied along with the “–manifest” option, I could never get the build to succeed. So finally I had to settle for the above described build procedure that doesn’t utilize the “–manifest” command option Support for manifests is only available for releases 2016.05 and newer!. Here’s an example of ABE utility invocation using the “–manifest” option,

$ ../abe/abe.sh --manifest gcc-linaro-5.3.1-2016.05-linux-manifest.txt --release 2016.05 --tarball --build all