Please note: THIS PAGE IS NOT FINISHED

To create a crosscompile toolchain I searched the internet and found:

• http://venus.billgatliff.com/node/18
• http://kegel.com/crosstool
• http://scratchbox.org

• http://kegel.com/crosstool/crosstool-0.42/doc/crosstool-howto.html
• http://freaknet.org/martin/doc/crosstool-vars.html

Crosstool can be used to create a build environment for ARM targets, but it doesn’t seem to be as polished as Scratchbox.

While building Crosstool for armv51b I got the following error scripts/kconfig/mconf.c:91: error: static declaration of ‘current_menu’ follows non-static declaration scripts/kconfig/lkc.h:63: error: previous declaration of ‘current_menu’ was heremake[1]: *** [scripts/kconfig/mconf.o] Error 1 etc.

This error is a common one aparently because Google returns a lot of hits. One solution is to patch the mconf.c file and another is to use a different gcc compiler version. I chose to switch to a different compiler version.

Crosstool toolchain As an example to build my own Crosstool toolchain I copied demo-armv5b.sh, commented the current active eval ... line and added a new one: eval `cat armv5b-softfloat.dat gcc-4.0.0-glibc-2.2.5.dat` sh all.sh –notest.

After running the adapted Crosstool script a new Crosstool toolchain is available: - gcc 4.0.0 - glibc 2.2.5

Below is a list of steps I performed in getting scratchbox installed and compiling a package. These steps originate from the Scratchbox website and aditional/more detailed information about these steps can be found in the Scratchbox install manual.

• Add an apt source to /etc/apt/sources.list using vi or other text editor:

#
# Scratchbox
# 
deb http://scratchbox.org/debian ./

• Update apt sources:

# apt-get update

• Donwload and install scratchbox utilities and toolchain for ARM architecture:

# apt-get install scratchbox-core scratchbox-toolchain-arm-gcc3.3-glibc2.3 scratchbox-devkit-cputransp

Note: Without the toolchain the scratchbox tool will not work. Also the cpu transparency is needed as a seperate install.

• Download and install qemu (emulator for e.g. arm architecture)

# apt-get install qemu

• Add a user to the scratchbox toolkit:

# sb-adduser <username>

• Run the graphical scratchbox configurator:

# sb-menu

• Logon the the Scratchbox environment using the registered username:

# /scratchbox/login

• Install the c library in the Scratchbox environment using the following command:

[sbox-HOST: ~] > sb-conf install -c

• Configure a new project using the sb-menu, naming it ‘NA-1400’.

[sbox-HOST: ~] > sb-menu

• See the installation manual mentioned above on howto configure a target.

• Once a target is activated a test program can be compiled

[sbox-NA-1400: ~] > tar xfz /scratchbox/packages/hello-world.tar.gz
[sbox-NA-1400: ~] > cd hello-world
[sbox-NA-1400: ~/hello-world] > ./autogen.sh
[sbox-NA-1400: ~/hello-world] > make

• If these steps compile without problems then there should be an ARM executable named ‘hello’. Get the properties by invoking file hello. This results in:

[sbox-NA-1400: ~/hello-world] > file hello
hello: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.0.0,
dynamically linked (uses shared libs), not stripped

This shows the executable is compiled for ARM, uses shared libraries and is not stripped

• To test the file program:

[sbox-NA-1400: ~/hello-world] > ./hello
Hello World!

• At this point it looks like everything is in order and the hello world program can be tested on the NA-1400. The easiest way to do this is to copy the file to the shared folder on the NA-1400. Then logon to the NA-1400 using the serial terminal or SSH connection and execute the program.

Using the Scratchbox toolchain I was able to compile the hello.c and hello-world examples and ran them on the NA-1400. However programs using a glibc library fail to run on the NA-1400 because they are built agains glibc version 2.3 while the current version on the NA-1400 is 2.2.6.

There seem to be a few solutions to overcome this problem:

1. Build a new custom toolchain to get packages compiled against glibc version 2.2.6 using this tutorial.
2. Upgrade the glibc version on the NA-1400 to 2.3.2.
3. Statically link the new software.
4. Compile a complete new image based on the latest kernel and glibc.

This would be a good choice, it leaves the current software on the NA-1400 as is and allowes adding new software transparantly. On the other hand I have a gut feeling that this is a difficult process which might not succeed through lack of proper patches. Remember, the distribution used for the NA-1400 is most probably a highly adapted one with many undisclosed patches.

This should be feasable but might break existing software on the NA-1400 (Normally glibc is backward compatible). Also the ugrade process is probably difficult as the glibc library is used for almost everything on the system.

Useful links:

• http://groups.google.nl/group/comp.os.linux.development.system/browse_thread/thread/dbc72c5f1f833307/7b2d19201ec7a048
• http://www.debian.org/ports/hurd/extra-files/hurd-upgrade.txt

This might be the quickest way to see results, but is also one of the less beautiful ones as it wastes a lot of disk- and memory space because every process loads the same code over and over again.

This could be the ultimate goal for me as it will give me all the controlls over the new system. This option will probably take the most time and I doubt if I can get this far by myself....