Crosscompiling Outside of Arago

Some users may prefer to cross-compile their applications outside of the standard Arago/OpenEmbedded flow. It maybe specifically useful and easier for new projects in their prototyping and proof-of-concept stages or for any smaller applications in general. This way users don't have to worry about creating OE "recipes" for their applications and setting up the entire OpenEmbedded build environment for Arago.

In order to cross-compile an application, written in C/C++, we'd need the same CodeSourcery Lite toolchain (refer to Getting CodeSourcery Toolchain for obtaining one).

Assuming, that the toolchain was installed under, we need to set our   environment variable:

$ export PATH=/opt/arm-2007q3/bin/:$PATH

Verify, that everything is configured properly:

$ arm-none-linux-gnueabi-gcc --version arm-none-linux-gnueabi-gcc (CodeSourcery Sourcery G++ Lite 2007q3-51) 4.2.1 Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

At this point we can write a simple "Hello world" application, let's call it :

int main {        printf("Hello world\n"); return 0; }
 * 1) include 

Let's cross-compile it:

$ arm-none-linux-gnueabi-gcc -o hello hello.c

And execute it on the platform, running Arago filesystem:

root@arago:~# hello Hello world

In this case  header file is provided by the toolchain as part of the standard GLIBC install and the run-time code for   function is provided by the run-time portion of GLIBC, installed in the Arago filesystem.

Now it is time to extend our application to use some of the additional libraries, provided by Arago filesystem. For example, let's assume we want to use the sound API of the ALSA (Advanced Linux Sound Architecture) project and call it :

int main {        printf("Using ALSA %s\n", snd_asoundlib_version); return 0; }
 * 1) include 
 * 2) include 

Obviously, trying to build this code would give us an error about missing  header file, as ALSA is not part of the toolchain:

$ arm-none-linux-gnueabi-gcc -o sndtest sndtest.c sndtest.c:2:28: error: alsa/asoundlib.h: No such file or directory

We need to get the header files and libraries for ALSA on our host system in order to compile and link our sample application. Luckily, everything we need is provided by Arago in form of  packages. Some of the packages, like dynamic libraries, are installed to the Arago filesystem. But header files and static libraries are not installed and usually are part of the  packages. We would need them extracted somewhere on our host system for cross-compilation.

Our sample application using ALSA API would require the following  packages:

alsa-dev_1.0.18-r0.1_armv5te.ipk libasound2_1.0.18-r0.1_armv5te.ipk alsa-lib-dev_1.0.18-r0.1_armv5te.ipk

provides all the header files. provides the dynamic library (which is also installed on the Arago filesystem for run-time operation). And  provides the necessary support to link our application against the dynamic library.

Normally, handling  files in the OpenEmbedded environment requires a tool called. But it is possible to extract package content without  using only standard Linux tools (  and  ) and don't worry about the package database:

$ ar -p alsa-dev_1.0.18-r0.1_armv5te.ipk data.tar.gz | tar -zx $ ar -p libasound2_1.0.18-r0.1_armv5te.ipk data.tar.gz | tar -zx $ ar -p alsa-lib-dev_1.0.18-r0.1_armv5te.ipk data.tar.gz | tar -zx

Above commands would extract the actual content of  inside each of the   packages to the current directory, re-creating the directory hierarchy of the target. Specifically, header files will be placed under  and libraries under

Everything is now ready to cross-compile our sample application and link it against the ALSA library. We'd need to add additional parameters to the command line:

-Iincdir

To add an additional  directory to look for header files.

-Llibdir

To add a  library directory.

-llibname

To link against a  library in the   directory (the name should not have the "lib" prefix).

The resulting command would look like:

$ arm-none-linux-gnueabi-gcc -o sndtest sndtest.c -I./usr/include/ -L./usr/lib/ -lasound

When the produced binary is executed on the platform, running Arago filesystem, it would output the result of the  function call, which returns the current version number of the ALSA library:

root@arago:~# sndtest Using ALSA 1.0.18

The same approach can be used to link applications against other libraries. For example, to use a jpeg library, we'd need  for the actual dynamic library (which is part of the "demo" Arago filesystem) and   for header files, support for linking against dynamic library and the static library.

Sometimes libraries come with support for GNU Autotools and freedesktop.org pkg-config, but their use in the cross-compiling environment is not trivial and it is recommended to convert user's applications to the provided Arago/OpenEmbedded flow.