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] |
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] |