In theory autotools has good support for configuring a project to be crosscompiled, and for some projects it works very well. Often it is simply enough to set the $PATH to your compiler dir, and say ./configure --host=arm-linux. However there are some patholgical projects that blow chunks violently when presented with a crosscompile action that they claim to support. A good example of such an evil project is perl. This generates an executable called miniperl which is used in the build process to generate the final perl executable. But it does not take care to generate miniperl using a host compiler that is different from the target compiler, so the build process generates miniperl fine, just that it can't execute on the build host since it is an Arm ELF app. Therefore the build process drops dead. A common issue is that the configure script wants to compile a short test app with the crosscompiler, which is fine, but it then wants to run it and look for a returncode. I added some infrastructure to the Octotux build tools scripts to enable this by prepending the helper script name to the app to be run remotely via ssh, and to capture the retcode transparently and return it to configure. Since the Octotux system captures any edits into a patchfile anyway, this is a relatively non-fragile solution. One that caused much pain this last week is sqlite, which suffered from another common problem, the generated configure file wants to determine if include files or libraries exist, but decides that it cannot because you are crosscompiling. In this case it was the configure logic around the readline library that felt unable to survive the crosscompile action with an explicit test and fatal error. Despite hacking that out and overriding various configure defines and makefile definitions in the RPM specfile that tries to build it, there are still problems. Edit 2006-08-13 sqlite seems to be compiled and packaged okay now, needs readline and ncurses. Python is another monster like Perl. There are some patches to help here, but they are incomplete http://mail.python.org/pipermail/python-dev/2003-October/039690.html The guy who posted them had the whole crosscompiling deal politely rejected in 2003, yet the configure half supports it, even though the build process can't handle it at all. The patches in the link seem to magically require host-compiled python and Parser/pgen, which are used on the host as part of the build process, but they are not generated anywhere, and although python can come from Fedora python, pgen isn't available even in the -devel package. So it looks like you must compile the damn thing twice and hack the host packages into the crosscompile build process!