Crosscompiling Outside of Arago

From AragoWiki

Jump to: navigation, search

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 /opt/arm-2007q3, we need to set our PATH 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 hello.c:

#include <stdio.h>

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

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 stdio.h header file is provided by the toolchain as part of the standard GLIBC install and the run-time code for printf() function is provided by the run-time portion of GLIBC (/lib/libc.so), 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 sndtest.c:

#include <stdio.h>
#include <alsa/asoundlib.h>

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

Obviously, trying to build this code would give us an error about missing alsa/asoundlib.h 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 ipk 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 -dev packages. We would need them extracted somewhere on our host system for cross-compilation.

Our sample application using ALSA API would require the following ipk 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

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

Normally, handling ipk files in the OpenEmbedded environment requires a tool called opkg. But it is possible to extract package content without opkg using only standard Linux tools (ar and tar) 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 data.tar.gz inside each of the ipk packages to the current directory, re-creating the directory hierarchy of the target. Specifically, header files will be placed under ./usr/include and libraries under ./usr/lib

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 incdir directory to look for header files.

-Llibdir

To add a libdir library directory.

-llibname

To link against a libname library in the libdir 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 snd_asoundlib_version() 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 libjpeg62_6b-r8.1_armv5te.ipk for the actual dynamic library (which is part of the "demo" Arago filesystem) and libjpeg-dev_6b-r8.1_armv5te.ipk 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.

Personal tools