This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 http://scratchbox.org/ ). 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
arm-gnueabi.
 
My starting point were the two following pages.
http://scratchbox.org/wiki/CrossToolToolchain
http://www.scratchbox.org/wiki/ForeignToolchains
 
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
code.

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

--Frederic

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
that:
 

	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
http://ftp.us.debian.org/debian
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
wget
http://ymorin.is-a-geek.org/download/crosstool-ng/crosstool-ng-1.4.1.tar
.bz2
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 
Make
# 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
mv
/scratchbox/CTNG/usr/src/crosstool-ng-1.4.1/x-tools/arm-unknown-linux-gn
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++
arm-unknown-linux-gnueabi/include/
# 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 ...
scratchbox
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
/scratchbox/compilers/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gn
ueabi-gcc --version
cd
darcs get --set-scripts-executable
http://scratchbox.org/repos/1.0/sb-toolchain-extras
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/create_toolchain_conf.py
# 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
~/sb-toolchain-extras/meta/alien-tc/arm-unknown-linux-gnueabi.conf
# 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
tools
# installed in sb-toolchain-extras:
# patch strace-4.5.15 - file.c: include <linux/dirent.h> --->
<bits/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
meta/alien-tc

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

RELEASE = 9


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

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

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

CRUNTIME_FILES = $(COMPILER_DIR)/$(TARGET)/lib/libgcc_s.so.1 \
                 $(COMPILER_DIR)/$(TARGET)/lib/libgcc_s.so \
                 $(COMPILER_DIR)/$(TARGET)/lib/libstdc++.so.6.0.10 \
                 $(COMPILER_DIR)/$(TARGET)/lib/libstdc++.so.6 \
                 $(COMPILER_DIR)/$(TARGET)/lib/libstdc++.so

BINUTILS_FULLVER = 2.19.1

CC_VER = 4.3
CC_GCCVER = 4.3.2
CC_FULLVER = 1:$(CC_GCCVER)
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
2.6.28-13-server
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 http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]