Maemo SDK concepts

Developing software using the maemo SDK is quite similar to using a Symbian OS SDK. You write, compile, and run the code, usually using an Integrated Development Environment (for example, carbide.c++ for S60, Visual Studio for Windows Mobile, or ESbox + Eclipse for the maemo platform). The Symbian OS SDKs include a phone simulator, which is a Windows executable capable of running Symbian OS software on an x86 workstation. The Windows Mobile SDK kits also include similar phone emulators and are capable of running .NET Compact Framework software.

The maemo SDK also enables running maemo software on the development workstation, but the approach is different. There is no single program to simulate the target device. Instead, Scratchbox is used to run a functional maemo platform instance inside the development workstation.

Symbian OS SDK

Windows Mobile SDK

The maemo SDK

* With the maemo SDK, it is possible to run ARM binaries within an x86 workstation using QEMU, but that advanced topic is not discussed here.


The work horse of maemo development is Scratchbox, a cross-compilation toolkit. The fundamental idea is that Scratchbox works as an independent "sandbox" inside your GNU/Linux workstation. This sandbox contains all the required compilers, files, development headers, and libraries needed to develop software for a maemo device.

Sandboxing has several benefits. Both the GNU/Linux workstation (host system) and the maemo device (target system) run on GNU/Linux-based OS so you should make sure that libraries of the host system do not cause problems when compiling binaries for the target device. The scratchbox also supports several 'targets' (but unfortunately only one target can be active at a time). Usually one target is for developing for x86 with the whole runnable maemo platform and another target for creating the binaries for the actual device. You can also have targets for different maemo platform release versions (for example, maemo 2.0 'mistral', maemo 3.0 'bora', maemo 4.0 'chinook', maemo 4.1 'diablo', etc.).

For the developer, the scratchbox looks like a separate GNU/Linux operating system inside the actual GNU/Linux workstation. The developer can 'log in' to the scratchbox, and everything outside the scratchbox becomes 'invisible', that is, the directory /usr/bin inside the scratchbox contains different files than /usr/bin of the actual GNU/Linux workstation.

Scratchbox is a completely different concept than VMWare. VMWare creates a virtual machine inside your real machine. Scratchbox uses wrappers and creates boundaries within the file system to prevent unwanted access to the host GNU/Linux workstation's files.

X Window System and Xephyr

X Window System basics

Before learning what Xephyr is and what it does, it is essential to understand the basics of the X Window System.

X Window System provides the basic framework for building GUI environments: drawing and moving windows on the screen and interacting with a mouse and/or keyboard.

The X Server in the X Window System gathers user input (keyboard, mouse) and passes it to X aware applications, called X clients. The X Server also provides a way for X clients to display graphical output. The image below illustrates a very simplified picture of this.

X Server

Communication between the X Server and X clients are network transparent. This means you can run a Web browser on a different computer, which then uses the X Server on your workstation.


Why use Xephyr?

The target maemo device (Nokia 770, Nokia N800, or Nokia N810) will have an X Server running on it, just like your GNU/Linux workstation. The screen resolution for the Nokia 770, Nokia N800, and Nokia N810 is 800 x 480 pixels, while your GNU/Linux workstation could have any resolution, for example, 1024 x 768, 1600 x 1200, or 1440 x 900 pixels.

Scratchbox inside a GNU/Linux workstation

Xephyr is started, its window size is set to 800 x 480 pixels, and the maemo platform inside Scratchbox is told to use Xephyr as its X Server. This way it is possible to have a single 800-x-480-pixel window in the GNU/Linux workstation desktop, which displays the maemo content.

It doesn't matter if Xephyr is run outside the Scratchbox, since the Scratchbox affects only the file system. Sockets and shared memory are accessible both from the in and outside of the Scratchbox.

Running Xephyr

Application development tools

Binary packages vs. source code

For the end user, binary packages (that is, .sis packages in Symbian OS) are the easiest way to install software to the device. Unfortunately distributing binary packages is not a good solution if you want the widest possible audience for the open-source software. There are several different Unix-style operating systems (for example, GNU/Linux, OpenBSD, HP-UX, Solaris) and different distributions of these operating systems, which makes building binary packages for every operating system and distribution practically impossible, at least for a single developer or small development team.

Several GNU/Linux distributions (Debian, Ubuntu, Red Hat, maemo) distribute software as binary packages available from central repositories. The original developer is usually not responsible for maintaining the binary package for a certain distribution.

The graphical integrated development environments hide much of the complexities of building the software and making distributable packages (source code or binary). Nevertheless, you should know some basics about the underlying build system, as it helps you to diagnose possible problems which might occur, especially when porting software to the maemo platform.

Installing software from source code packages

The routine

When a source code package is released as defined in "GNU coding standards", chapter 7, there is a standard routine for installing the software it contains. So whether compiling the sources in the HP-UX server, in the GNU/Linux workstation, or inside the Scratchbox for a maemo Internet Tablet, this routine is the same.

The following example is just an imaginary case.

The GNU toolchain

The routine above requires that a working toolchain is available in the system.

In the GNU/Linux operating system (and, consequently, in the maemo platform), the GNU toolchain provides the complete set of compilers and tools required for building software from sources.

The GNU toolchain includes:

Brief explanation of the GNU build system (autotools)

Why is the GNU build system needed?

The GNU build system tries to solve a problem: The original developer knows nothing about the system where the source code is going to be compiled. Without autotools there wouldn't be a configure script to run *; instead, every user would have to manually edit the source and configuration files.

The GNU build system supports several compilers, operating systems, and environments, and therefore the usage may seem fairly complicated at first.

* It would be very tedious to manually write the configure script mentioned above because the script would be complex and grow very large. For example, the configure script for the monotone-0.35 version control system is 474KB in size.


GNU Autoconf tool, which is a part of the GNU build system, is used to create the configure script. The developer writes a* text file, which is then processed by the autoconf, generating the configure script. The file contains, for example, software name and version, dependency checks (is library x, version y available), and so on.

* The was earlier named as, but that naming has been deprecated. You might still see it in older source code packages.

For more information, see the Wikipedia entry about Autoconf.


In addition to, the developer writes one or more files. These files define which source files are compiled and how, where the binaries and datafiles should be installed, and so forth.

GNU Automake is a tool which processes these files, and generates files.

When the configure script is run, it processes these files and creates the actual Makefile files. These Makefiles are then used by the make, as mentioned earlier.

For more information about autoconf and automake, see

In brief

The software developer:

  1. Writes the > autoconf processes > creates a shell script configure.
  2. Writes the > automake processes > creates file(s).
  3. Packages all the files as distributable source code package.

The user who wants to install the software:

  1. Aquires the source code package.
  2. Runs the configure script > processes > creates Makefile(s).
  3. Runs the make > reads Makefile(s) > Calls the compiler with the correct parameters, builds the software.
  4. Runs make install > reads Makefile(s) > installs the built software to the desired location.

Eclipse and ESbox plug-in

The default IDE for the maemo development is Eclipse with ESbox plug-in.

Eclipse is an open-source software framework, commonly used as an Java IDE. It is extendable through plug-ins and support for other languages than Java has been added that way.