---

Overview

This page describes how to build your own SH cross-compile toolchain using the crosstool package. This documentation is supplied AS IS, without any warranty for suitability, or direct or indirect damages that might be caused by the information here although, of course, if you find any mistakes, it would be nice if you corrected them.

Full documentation on crosstool can be found at its home page http://www.kegel.com/crosstool.

Where to get crosstool

Get crosstool at http://www.kegel.com/crosstool/#download, the most recent version that's available which, at the moment, is crosstool-0.28-rc37. Don't bother with crosstool-0.27, that's too old to matter anymore, and the official release of crosstool-0.28 is allegedly imminent.

Furthermore, download and gunzip the tarball into a directory that will give you at least 1G (yes, that's 1 Gig) of build space underneath, since crosstool will generate a lot of temporary files in its build subdirectory. Note that this build space is separate from the actual eventual toolchain files -- you can arrange for those to be generated elsewhere.

Configuring the build files

As an example, assume you wanted to build a toolchain for an SH3. Once you unload the tarball, the files you would want to customize would be:

1. sh3.dat

2. demo-sh3.sh

3. sh3.config (if you care about optional kernel configuration)

which we can discuss one file at a time.

Configuring sh3.dat

The sh3.dat file specifies the build properties, including potential kernel config and glibc parameters. Here's an example:

KERNELCONFIG=`pwd`/sh3.config
TARGET=sh3-unknown-linux-gnu
TARGET_CFLAGS="-O -ml -m3"
GLIBC_CONFIGPARMS="no-z-defs=yes"
GLIBC_EXTRA_CONFIG="--without-fp"    # if no FPU, you'll want to add this

Configuring demo-sh3.sh

This file identifies where you want the downloaded tool sources to be placed, and where you want the toolchain to be generated, which can be outside of the crosstool directory itself. In addition , you have to uncomment exactly one of the calls to all.sh, depending on which versions of the GNU tools you want to download and build from. A sample demo-sh3.sh file:

#!/bin/sh
set -ex
TARBALLS_DIR=$HOME/downloads         # set this to what you want
RESULT_TOP=$HOME/result              # same here
export TARBALLS_DIR RESULT_TOP
GCC_LANGUAGES="c,c++"
export GCC_LANGUAGES
 
mkdir -p $RESULT_TOP
 
#eval `cat sh3.dat gcc-3.3.2-glibc-2.3.2.dat` sh all.sh --notest
#eval `cat sh3.dat gcc-3.3.3-glibc-2.3.2.dat` sh all.sh --notest
#eval `cat sh3.dat gcc-3.4.0-glibc-2.3.2.dat` sh all.sh --notest
 eval `cat sh3.dat gcc-3.4.1-glibc-2.3.3.dat` sh all.sh --notest
#eval `cat sh3.dat gcc-3.4.1-glibc-20040827.dat` sh all.sh --notest

You can see that this example will try to build a toolchain with gcc-3.4.1 and glibc-2.3.3, with the resulting toolchain itself being produced in the directory ${HOME}/result.

Doing the build

To perform the actual build, you just need to execute the appropriate script; in this case demo-sh3.sh. Because the underlying all.sh script requires that the LD_LIBRARY_PATH variable be unset, you have two choices. First, you can, of course, just unset and export that variable, then run the script:

$ export LD_LIBRARY_PATH=""
$ sh demo-sh3.sh

As an alternative, you can unset that variable just for the duration of that single command with:

$ LD_LIBRARY_PATH="" sh demo-sh3.sh

In either case, you can now go for lunch. Or dinner. When you get back, you should have the final toolchain in the "result" directory, at which point you can copy it elsewhere and set the appropriate PATH variable entries to pick up the actual executables.

NOTE: There was some debate as to whether you could relocate the generated toolchain directory after it had been built by crosstool. It seems to be possible with gcc versions gcc-3.x, but I'm not going to bet my life on it. Test it and see what happens.