Cross compiling (non-Qtopia) tips

From OESF

Just a couple of points should you be starting out cross-compiling console (or even X apps) which come as source tarballs (i.e. they have configure scripts, etc. already provided).

Note that first of all you need to follow the same instructions for setting up the cross-compiler and sourcing the scripts, etc., as for a normal Qtopia app build.

Then....

What do I tell configure?

Try something like:

 $ ./configure --build=i686-mandrake-linux --host=arm-linux

(Change i686-mandrake-linux for your own Linux flavour, actually just using i686-linux may be a generic solution? I don't know)

This works with about half of the configure scripts I've encoutered, i.e. configure runs fine and it can then be compiled by doing:

 $ make

That said, there's the other half where the configure script either hasn't been written to allow cross-compiling, or it just plain doesn't work. This is a pain but it happens. The complaint which the configure script normally produces is that it can't run a binary which it has created (unsurprisingly as it has tried to use the cross-compiler). Although painful, it's possible to edit the configure script by hand to eliminate the need for these various programs (whether by just knowing what it's trying to find out, or by compiling it your self and supplying the asnwer in the script).

Libraries and Header files

One of the main things that often goes wrong is that configure located native versions of the libraries and header files and attempts to compile with them. You need arm versions of those libraries and headers installed and point configure at them.

I keep an installation of sharp libs in /opt/sharplibs. If I need compile a library for the Zaurus, I add --prefix=/opt/sharplibs/arm to the ./configure command, and make install. I then tell any application to look there for libs and headers (headers in /opt/sharplibs/arm/include, libs in /opt/sharplibs/arm/lib)

Dealing with builds that try to execute code it just compiled

Some builds attempt to execute programs they just built as part of the build process. This might be done for various reasons. In my example below, the hatari emulator CPU builds two executables that it uses to generate code. Of course, if you are cross compiling, it is impossible to execute the code you just compiled and the build fails.

This causes an error that looks like this:

./build68k <./table68k >cpudefs.c
/bin/sh: line 1: ./build68k: cannot execute binary file
make[2]: *** [cpudefs.c] Error 126
make[2]: Leaving directory `/export/temp/src/hatari-0.80/src/uae-cpu'

In this case, it just compiled build68k, and it is attempting to run it and generate cpudefs.c There are two ways to get around this:

1. manually compile it with the native compiler and generate the cpudefs.c yourself - the only problem with this approach is that the code may generate different code depending on what processor it runs on. After all, there must be some reason to generate the code dynamically rather than can it and ship it with the distribution, right? It might be something like optimizations, where the program will compile, but may not run correctly. Unless you know that none of that is the case, this isn't really the best approach.
2. use the Zaurus to run the code and copy the resulting file (cpudefs.h) back to the build tree. It's more work, but it should be the safer way. You might even be able to mount your source tree on the zaurus via NFS.

Once you manage to get the code generated, put it into place in the source tree, and run make. The build should hopefully continue on.