Crosstool-ng: HOWTO use crosstool-ng for scratchbox toolchains

Frederic Roussel
Wed Jun 10 00:57:00 GMT 2009

Hi all,
Scratchbox, for those of you who don't know it, is a cross-compilation
toolkit designed to make embedded Linux application development easier.
( see ). It has been made prominent by being used
by the Maemo project.
As crosstool-ng is an amazingly good tool to generate cross-toolchains,
I wanted to play more with it and see how I could successfully build a
cross-toolchain for scratchbox. The example I'm giving is for
My starting point were the two following pages.
What I'm sending today is a complete step-by-step way to build a
toolchain with crosstool-ng for scratchbox. There is nothing
particularly challenging in that exercise, and most of my issues ended
up being an information chase through web pages, forums and even source

I understand that it might be lengthy and slightly off-topic, though I
firmly believe that it is one of the use case that will reveal
crosstool-ng to a number of developers.

By allowing a wider audience to use that tool, its use, reputation and
overall community support will get boosted.

Would there be an interest in me trying to formalize the following steps
in a script ?

Thanks again for giving us crosstool-ng


Here we go...

The first wiki page orients the crosstool-builder to build the crosstool
inside of a HOST target, that means the build will be done for the
underlying native processor. Of course I went through the lengthy
exercise and crosstool-ng greeted me with:
"Don't set LD_LIBRARY_PATH. It screws up the build."
As LD_LIBRARY_PATH is one of the corner stones of scratchbox, there is
really no way around it. I don't know why LD_LIBRARY_PATH screws the
build, but I trust the author that it indeed does screw it.
So I moved to the second page to actually build the toolchain on its
own, and build it as a Foreign Toolchain.
Of course it was not that simple. A small note on the wiki page states

	For systems with glibc version 2.4 or newer
	If you have glibc version 2.4 or above, you have to compile the
toolchain in e.g. Scratchbox itself. Create a target with a compiler
such as i686-linux-gcc3.3-glibc2.3 which is included in Scratchbox, then
follow the crosstool instructions.

Now as scratchbox is built around glibc-2.3 that really meant a
toolchain built on my Linux box, currently is Ubuntu 9.04, which is
irrelevant besides the fact it's using glibc-2.9. The toolchain I built
at first was therefore linked against glibc-2.9 and any attempt to run
it inside of scratchbox (to print it's version string as we will see
later) was issuing a stern message error saying that GLIBC_2.4 or later
was needed.
So I had no other choice but building the crosstoolchain inside of a
Jail. Here is how I did it:
# I just happened to have a 2TB slice under /scratchbox. The path is of
course, whatever you want.
mkdir /scratchbox/CTNG
# I picked Debian-etch for a number of reasons. First I'm very familiar
with it.
# "etch" is old enough to have glibc-2.3
# scratchbox is very Debian-centric
# I'm sure any other distro. Could have been used. I just didn't
debootstrap --arch=i386 --variant=buildd etch /scratchbox/CTNG
chroot /scratchbox/CTNG
export LC_ALL=C
apt-get -y --force-yes install less libncurses5-dev
apt-get -y --force-yes install autoconf automake
apt-get -y --force-yes install wget rsync bzip2 lzma
apt-get -y --force-yes install cvs subversion
apt-get -y --force-yes install bison flex texinfo libtool gawk
apt-get clean
# build the toolchain wherever you want, it doesn't matter
cd /usr/src
tar xvf crosstool-ng-1.4.1.tar.bz2
cd crosstool-ng-1.4.1
# that ugly command is to patch the regular expression so that
automake-1.10 can be recognized.
# I sent an e-mail a few days ago to the mailing list, Yann will
incorporate the change in trunk
sed -i -e 's/^automake=.*/automake=\\(GNU automake\\)
(|\\.[[:digit:]]{2,}|\\.[2-9][[:digit:]]*\\.)/' configure
./configure --local 
# I configured my toolchain for as latest as possible versions of
everything and arm-gnueabi
# If you're curious I can send the .config file
./ct-ng menuconfig
# Grab a coffee and a sandwich ...
./ct-ng build

Okay, now we have a crosstoolchain that is linked against glibc-2.3 and
is now ready to be imported into scratchbox. The import exercise is
based on the scratchbox wiki page with the help of some forums reading.

# Move the toolchain to the scratchbox compilers area
ueabi/ /scratchbox/compilers/
cd /scratchbox/compilers
# Copy the specs from the latest scratchbox provided compiler to the
CTNG one.
# Clearly that's an approximation and that will have to be addressed in
a formal way...
cp cs2007q3-glibc2.5-i486/gcc.specs arm-unknown-linux-gnueabi
# This far from elegant link is needed. I have no clue why. Ctng doesn't
create that directory.
# there must be a good reason for doing so, but down the road it's
needed by scratchbox ...
ln -s arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/include/c++
# Change some permissions. Needless to say that all the commands have
been executed, so far, as root
chown -R frasc.frasc arm-unknown-linux-gnueabi/
chown -R frasc.frasc /scratchbox/device_tools/
# Keep following the wiki page ...
sb-conf setup host -c host-gcc -d debian-etch:doctools:git:perl:svn
sb-conf select host
sb-conf install -cde
# That's to make sure the tools will work inside of scratchbox
ueabi-gcc --version
darcs get --set-scripts-executable
cd /scratchbox/compilers
# Okay, now we hit the first real snag.
# In the "configure" section they propose to use a configuration tool:
# ~/sb-toolchain-extras/confhelper/
# Nope. Forget it. I guess a newer version will be needed to understand
the new
# layout, particularly sys-root.
# So just take a live example
cp cs2007q3-glibc2.5-arm7/build-config
# And edit it manually. It's not that tough.
vi ~/sb-toolchain-extras/meta/alien-tc/arm-unknown-linux-gnueabi.conf
cd ~/sb-toolchain-extras/
# Before building, there is a patch that must be done in one of the
# installed in sb-toolchain-extras:
# patch strace-4.5.15 - file.c: include <linux/dirent.h> --->
# My take is that the newer versions of linux kernel have changed enough
# so that including <linux/dirent.h> will not work. I've honestly not
investigated any further.
make CONFIG=meta/alien-tc/arm-unknown-linux-gnueabi.conf -C
meta/alien-tc all-sums
make CONFIG=meta/alien-tc/arm-unknown-linux-gnueabi.conf -C

Here is arm-unknown-linux-gnueabi.conf file I came up with. I'm sure it
can be generated by a script aware of crosstool-ng as opposed to trying
to guess the values as the scratchbox python script attempts to do.
--- 8< --- snip --- 8< --- snip --- 8< --- snip --- 8< --- snip --- 8<
--- snip 
COMPILER_NAME = arm-unknown-linux-gnueabi

ALIEN_TC = yes


COMPILER_PACKAGE = scratchbox-toolchain-$(COMPILER_NAME)
ARCH = arm                                              
SUB_ARCH = arm                                          
VENDOR = unknown-
TARGET_END = -gnueabi

HEADERS_DIR = $(COMPILER_DIR)/$(TARGET)/sys-root/usr/include
LINUX_HEADERS_SUBDIRS  = linux asm asm-generic             

LIBC_VER = 2.9
LIBC_FILES_BINS = $(TARGET)/sys-root/usr/bin \
                  $(TARGET)/bin \
                  $(TARGET)/sys-root/sbin \
                  $(TARGET)/sys-root/lib \

                 $(COMPILER_DIR)/$(TARGET)/lib/ \
                 $(COMPILER_DIR)/$(TARGET)/lib/ \
                 $(COMPILER_DIR)/$(TARGET)/lib/ \


CC_VER = 4.3
CC_GCCVER = 4.3.2
CC_DEBIAN_DIR = gcc-3.4-debian

CHECKSUM_FILE = ../../$(CONFIG:.conf=.checksums)
--- 8< --- snip --- 8< --- snip --- 8< --- snip --- 8< --- snip --- 8<
--- snip 

Now we start trying it out:
sb-conf setup new -c arm-unknown-linux-gnueabi -d
cputransp:debian-etch:doctools:git:perl -t qemu-arm-cvs-m
sb-conf select new
sb-conf install -cdeF
I could then cross compile and execute a program but got:
FATAL: kernel too old
> cat /proc/sys/kernel/osrelease
Well my glibc was compiled against 2.6.29 kernel headers. I just
upgraded my base kernel to 2.6.30 and voila ... :-)


For unsubscribe information see

More information about the crossgcc mailing list