Building a hello world application/de

From Openmoko

Jump to: navigation, search



Diese Anleitung setzt voraus, dass man die Schritte in Building_Openmoko_from_scratch durchgeführt hat.

Das Kommandozeilen-Programm

Man speichert den mehr oder weniger Standard-"Hallo Welt!"-Code in hello.c.

#include <stdio.h>

int main()
  printf ("Hello World\n");
  return 0;

Kompilieren: Der falsche/einfache Weg

Davon ausgehend, dass das derzeitige Arbeitsverzeichnis /home/moko ist, und man den Quellcode in /home/moko/hello.c gespeichert hat, sollte es möglich sein die Anwendung zu kompilieren mit

./build/tmp/cross/arm-linux/bin/gcc -o hello hello.c


Davon ausgehend, dass man Einrichten einer USB Verbindung durchgeführt hat und eine funktionierende Verbindung zu einem emulierten oder echten Neo hat.

scp hello root@
ssh root@ /tmp/hello

Diese Befehlsreihenfolge sollte ein nettes "Hallo Welt!" ausgeben. Nebenbei bemerkt, dass Standard root-Passwort ist leer, also einfach Enter drücken.

GDK: Der falsche/einfache Weg

Das Erstellen einer GDK Anwendung ist geringfügig schwieriger, aber trotzdem wert es auszuprobieren. Es erfordert die Benutzung von pkg-config um die benötigten ARM header files und Libraries anzugeben.

Gegeben sei main.c:

#include <gtk/gtk.h>

gchar *hello = "Howdy";
gchar *world = "World";
GtkWidget *label;
gchar *labeltext;

void buttoncb(GtkWidget *widget, gpointer data)
if (labeltext == hello)
   labeltext = world;
   gtk_label_set_text(GTK_LABEL(label), labeltext);
else if (labeltext == world)

int main(int argc, char *argv[])
GtkWidget *window;
GtkWidget *button;

gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
button = gtk_button_new();
labeltext = hello;
label = gtk_label_new(labeltext);
gtk_container_add(GTK_CONTAINER(button), label);
g_signal_connect(G_OBJECT(button), "clicked", G_CALLBACK(buttoncb), NULL);
gtk_container_add(GTK_CONTAINER(window), button);

return 0;

You must first point pkg-config to the proper directory:

export PKG_CONFIG_PATH=/home/username/moko/build/tmp/staging/arm-linux/lib/pkgconfig

And set up an environment variable to make things easier:

export OMDIR=/home/username/moko

The compile/link line is rather long - you will only want to do this once before you decide to create a shell script or make file:

$OMDIR/build/tmp/cross/arm-angstrom-linux-gnueabi/bin/gcc -L $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ \
                   -Wl, rpath-link, $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ -Wl, -O1 -g -o hw main.c \
                   '$OMDIR/build/tmp/staging/i686-linux/bin/pkg-config --cflags --libs openmoko-libs gtk+-2.0'

Then copy and run as in the original hello world command line program above.

Why was it the wrong way?

Openmoko provides a precompiled Toolchain package for that. It also comes with some scripts that make your life much easier. Besides, you don't need OpenEmbedded to build applications. If you do want to customize your complete distribution, then read on how to use bitbake when building stuff. In any way, at least you now know that you can easily cross compile for Openmoko.

The Right Way: Using the gnome build system

Even if I am no expert in this - somebody had to make a start so I'll write down everything I still believe to remember from my 1st 'real' gnome application that used the autotools and all: I have never been able to find a good tutorial for making a "canonical" gnome application - and such a tutorial is urgently needed.

Since I know that many of these things will be missing or even inaccurate in the 1st step - if You find out to make it work better or at all - please document how to do this.

Creating the necessary documentation files and directory structure

First of all go into the directory you want to be the topmost application of yout new application, and create the following files:

AUTHORS A list of all authors that took part in developing this project
COPYING The copyright notice. Favourably the GPL
INSTALL This file should contain the information how to build and install this program
README This file should contain all important information about the program including what the program was written for.
NEWS The name of this file should be self-describing
TODO The wishlist of your project
Changelog A list of the major changes to your project

I remember that some of these files were mandatory - it's better create them all

Then create a directory named 'src - and copy the source code of the program there.

The configuration of the autotools

What is to be said to this section is that I included some requirements like gnome-vfs to the requirements not because our application actually needs these packages but because it was very hard to find out how to do so - and I therefore wanted to document how to add them.

If anybody doesn't like this approach - feel free to edit this wiki.

This file is a shell script that calls all autotools in the right order and with the right parameters so they will in the end generate the standard configure script that will detect how to build our program.

#! /bin/sh
# Most if not all of the contents of this file was taken from the openmoko
# sample application as it was shipped with the openmoko toolchain on
# January 31st, 2008

srcdir=`dirname $0`
test -z "$srcdir" && srcdir=.


(test -f $srcdir/ || {
        echo -n "**Error**: Directory "\`$srcdir\'" does not look like the"
        echo " top-level $PKG_NAME directory"
        exit 1

which || {
        echo "You need to install gnome-common from the GNOME CVS"
        exit 1


This file tells what the configure script has to do - and which parts of the intelligence delivered with the tools that generate the configure script we need.

I documented every line of which I found out what it actually does. The first line is for to tell the emacs text editor that it has to treat this file as an autoconf file.

#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

# Tell autoconf to check what version of autoconf we need.

# Initialize autoconf and tell it what program we wrote, the version
# of our program, and the address bug reports have to be sent to.

# tell autoconf where to put the temporary files it generates 

# This one is thaken from the "Migrationg to gnome Documentation Build
# utilities". No Idea, what it does.

# give autoconf the name of a file whose existence is a hint that
# autoconf has been started from the right directory. 

# Tell autoconf where to put the output file that contains all
# definitions our C program will need

# Initialize automake, and tell it to tell the C compiler to output as
# many warnings as it can
AM_INIT_AUTOMAKE([-Wall foreign])

# The GNU Gettext version we used for internationalization of our
# program... 
# ...Or alternatively the local gnu gettext installation

# Check for a C compiler

# Include all m4 macros that have to do with the language C

# ???

# ???

# Checks for programs.

# We need the following type definitions from autoconf - or somebody else.

# AC_CHECK_LIB(libgnome-2.0, gnome_help_display_uri, [AC_DEFINE(HAVE_LIBGNOME, 1)])

# Prepare building the gnome documentation of this program

# Checks for libraries.
dnl Checking for the required libraries.


# Gettext wants to know the path to the top directory and such things...

# Checks for the header files we include.
AC_CHECK_HEADERS([fcntl.h stdlib.h string.h sys/vfs.h])

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions that we really need.

# A list of all configuration files we have to generate
AC_CONFIG_FILES([Makefile src/Makefile src/images/Makefile po/]) #help/Makefile 

# Tell autoconf to start outputting whatever it has to.

This file is a template top-level-Makefile that will be filled with life by the configure script.

One thing that is added to the standard Makefile is code for automatically generate the _control-file mentioned above on a make dist

# A list of all subdirectories.
SUBDIRS = src po # help

# Allow automake to interpret m4 macros (needed for interpreting
# gettext's
# Files that aren't source files and still have to be in the tarball

# An (currently unused) extension to the "install" target

	echo "Package: @PACKAGE_NAME@">$@
	echo "Version: @PACKAGE_VERSION@">>$@
	echo "Description: An voice recorder that can stop recording during silence">>$@
	echo "Section: openmoko/applications">>$@
	echo "Priority: optional">>$@
	echo "Maintainer: your_name">>$@
	echo "Architecture: armv4t">>$@
	echo "Homepage: (The homepage of this project)">>$@
	echo "Depends: gtk+ alsa-lib libogg libvorbis gnome-vfs libgnomeui">>$@
	echo "Source: \$${SRC}">>$@

This file is a template Makefile that when filled with life by the configure script will compile our code.

The most important step here is to tell which files our program consists of.




bin_PROGRAMS = hello
hello_SOURCES = hello.c

Now the instructions on how to generate a gnome build system for our application should be nearly working. In order to generate a .tar.gz- archieve of the complete project that contains the full build system just type the following two lines:

make dist

What still has to be done is internationalization: A very fine feature of open-source software is that it is possible to translate them to nearlly all languages - and normally sooner or later somebody will have done this.

The only thing that has to be done so our program can easily be internationalized is the following:

  • get a gettext.h file and copy it to your src directory
  • add an #include gettext,h to all source files that contain text that can be translated.
  • add an _( in front of all strings that might be translated and an ) after the string.

Our source file looks now like this:

#include <stdio.h>
#include "gettext.h"

int main()
  printf (_("Hello World\n"));
  return 0;

Building our new package

I never used the offical openmoko toolchain, so no documentation for this for now - even if I don't think there is any magic there. Since the documentation of the MokoMakefile is rather good, I will document this approach - that I actually used - neither.

Personal tools