Category Archives: Programming

Developing shared libraries with Eclipse CDT

Consider the following not so uncommon scenario: you have a shared library project in Eclipse and an executable project which uses the shared library.

I found that you have to do some additional things for building, running and debugging the executable project in Eclipse (note that I’m doing this on Linux using CDT 4.0.3):

Define your shared library’s project as a reference for your application. In order to do so open the project properties of the executable project, go to project references and select the shared library project (where in my case “shared” is also the name of the shared library).

In the project settings of your executable project, add the shared library to the linker settings, as shown in the following screenshot:

Bear in mind that the library search path must be adjusted every time when switching between Debug and Release versions.

In the project settings of your executable project, add the working directory of your shared library project to the compiler include path, as shown in this screenshot:

Now you should be able to compile your application, but in order to run it from within Eclipse, there’s a last step that needs to be done:

In the run dialog (top menu Run -> Open Run Dialog), define the LD_LIBRARY_PATH variable as ${workspace_loc}/shared/Debug/, as shown inthe following screenshot.

Again, this needs to be adjusted when switching between Debug and Release versions.

All this is very tedious stuff, so hopefully this will be a bit improved in the upcoming CDT releases.

Debugging multiple processes with Eclipse CDT

For debugging a child process on Linux, gdb has the ability to step into a child process after fork and exec. This behavior can be enabled with the follow-fork-mode child statement.

Put the statement

set follow-fork-mode child

in the .gdbinit file, located in the project work directory.
Now, setting some breakpoints in the code of the child process will cause gdb to halt execution.

Btw, I’ve looked for a corresponding GUI option in the debug dialog (CDT version 4.0.3), but I found none. So it seems that creating a .gdbinit file is currently the only solution for this.

Building a GNU ARM cross-compiler toolchain on Mac OS X

I’m starting a new embedded project with ARM7 processor in March so I wanted to play around with the GNU ARM toolchain. Basically I’m interested in doing cross development on my Macbook Pro on Mac OS X, using a GCC cross compiler together with Eclipse CDT. We’ll see if that works out. 😉

So as a first step, here is how I built a GNU ARM toolchain on Mac OS X (this should be no different than building the toolchain on Linux):

First download and unpack the necessary packages: binutils, gcc, newlib and gdb.

$ mkdir ~/crossgcc && cd ~/crossgcc
$ wget
$ tar jxf binutils-2.18.50.tar.bz2
$ wget
$ tar jxf gcc-4.2.3.tar.bz2
$ wget
$ tar zxf newlib-1.16.0.tar.gz
$ wget
$ tar zxf gdb-6.6.tar.gz

The installation directory should be /usr/local/crossgcc.

$ sudo mkdir /usr/local/crossgcc
$ sudo chmod 777 /usr/local/crossgcc

First we build the binutils:

$ mkdir build-binutils && cd build-binutils
$ ../binutils-2.18.50/configure --target=arm-elf \
--prefix=/usr/local/crossgcc/ 2>&1 | tee configure.log
$ make all install 2>&1 | tee make.log
$ export PATH=$PATH:/usr/local/crossgcc/bin

Build the gcc compiler with C/C++ support:

$ cd ../gcc-4.2.3
$ ln -s ../newlib-1.16.0/newlib .
$ ln -s ../newlib-1.16.0/libgloss .
$ cd ..
$ mkdir build-gcc && cd build-gcc
$ ../gcc-4.2.3/configure --target=arm-elf \
--prefix=/usr/local/crossgcc/ --with-newlib \
--with-gnu-as --with-gnu-ld --enable-languages=c,c++ 2>&1 | tee configure.log
$ make all install 2>&1 | tee make.log

Build the gdb debugger:

$ cd ..
$ mkdir build-gdb && cd build-gdb
$ ../gdb-6.6/configure --target=arm-elf --prefix=/usr/local/crossgcc/
$ make all install 2>&1 | tee make.log

Eclipse CDT on Mac OS X

Nowadays, it seems that the Eclipse C/C++ Development Tools (CDT) is quickly becoming a de-facto standard especially for Embedded Development. As Bill Graham points out, this is mainly the result of the efforts of embedded tools vendors or RTOS vendors, who have extended the CDT for cross-development environments with remote target debugging and the like.

Recently I’ve worked with Eclipse-based Nucleus EDGE from Mentor Graphics as an embedded IDE with Microtec compilers for a ColdFire target and was quite pleased with the overall development environment (comparing this to the old Nucleus EDE some years ago which was a set of macros to be imported in Microsoft Visual Studio 6, which led me to use vim and make on Cygwin as my main development tools. btw, if you are like me and vim is indispensable to you, then you can add vi functionality to Eclipse with viPlugin – this one is commercial, but there exists other plugins as well).

Now, as I’ve had some time to spend on my Macbook Pro, I wanted to know what the “vanilla” Eclipse CDT from has to offer for building self-hosted C/C++ applications with standard GNU C/C++ tools (the Apple GCC 4.0 compiler in that case).

As example source code I decided to use the famous rotating 3-D gear wheels from Brian Paul that has been converted to GLUT. The source code is in the public domain and can be found here.

$ gcc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO

On Mac OS X the OpenGL Utility Toolkit (GLUT) can be installed with MacPorts.

$ sudo port install glut

Then compile the program with

$ gcc -Wall -I/usr/X11R6/include/ -I/opt/local/include -L/opt/local/lib -L/usr/X11R6/lib -lglut -lglu -lgl -o gears gears.c

Looks familiar, no? 🙂

Now, on to the installation of the CDT release for Europa based Eclipse. CDT 4.0 runs with Eclipse 3.3 and is part of the Eclipse Europa simultaneous release. I’ve installed CDT 4.0.2 by entering the URL

in the Eclipse update manager to download the CDT features.

First open the C/C++ perspective

Then create an empty C project and select the Apple GCC toolchain.

Add the include directories /opt/local/include and /usr/X11R6/include in the project properties.

Now the required libraries need to be added to the linker settings.

After successful compilation, you will probably want to run the gears application, but you’ll see the following error message in the console

GLUT: Fatal Error in gears: could not open display:

This can be fixed by adding the display variable to the environment

Now you should be able to compile and run the gears application from Eclipse CDT in Mac OS X. 🙂

Finally trying out Maven 2

While many people are saying that Maven 2 is really a terrible terrible tool and stupid for great, great many reasons, recently I have finally been trying out Maven when I had to reorganize a generic algorithm into a separate library and I wanted to end up with a nice build process and managed dependencies.

On Mac OS X, Maven 2 can be installed easily via MacPorts. I started with the getting started guide and created my library project called mylib from the command line

$ mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DgroupId=com.mycompany.mylib -DartifactId=mylib

This has created a directory named mylib for the new project, and this directory contains a file named pom.xml. After moving my sources to ${basedir}/src/main/java, I had to resolve some external dependencies. My library is only dependent on Commons IO, Commons Lang and Commons Logging, so I added the following to the pom.xml under dependencies.


For Java 5 source compatibility you will have to add the following lines to your pom.xml:


Note that when compiling the application sources for the first time with

$ mvn compile

Maven will need to download all the plugins and related dependencies.

After successfully compiling the library’s sources, I’ve put my JUnit tests in the directory ${basedir}/src/test/java. They can be executed with

$ mvn test

In order to use Log4J logging during tests, put the log4j.xml file in the ${basedir}/src/test/config directory. Then add the following lines to the build/testResources element in your pom.xml:


A final tip: if you are using Eclipse, Maven can create Eclipse projects for you with

$ mvn eclipse:eclipse

which can then be imported into Eclipse as existing projects.

So far I’m quite pleased with Maven: I managed to create a new project for my library in no time (< 5 minutes), with a nice build process and dependency management. IMO much better than manually copying build.xml files from other projects and third-party jars around. 🙂

Building Mingw executables using Cygwin

Recently I wanted to compile a quick UDP test program on Windows and be able to ship it as a single stand-alone binary. I’ve compiled the source with GCC on Cygwin, and as you might already know, the executable is dependent on cygwin1.dll. This can be checked with the following command:

$ objdump -p udptest.exe | fgrep cygwin1.dll

It is possible to use the Cygwin development tools to build MinGW applications that do not depend on the Cygwin DLL and only depend on runtime libraries distributed as part of Windows.

The MinGW FAQ provides an answer on how use the Cygwin environment for development, yet generate non-Cygwin-dependant executables.

Adding the line


in /etc/profile before exporting PATH will have the effect that within the Cygwin environment the instance of GCC used is the MinGW version.

Note that the MinGW toolchain is gcc/g++ based but it’s using the WinAPI. If you want to use the UNIX Socket API by using the cygwin headers and libs, you have to supply the Cygwin DLL with your program. If this is not an option, you will need to rewrite specific parts of the project to conform with the winsock API.

Look here for some notes about Windows sockets versus Unix sockets. I did a rewrite by including the winsock2.h header file, like e.g.

#ifdef MINGW
#include <winsock2.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>

I’ve built the executable with

gcc -DMINGW -o udptest udptest.c -lws2_32

and verified the dependencies with

$ objdump -p udptest.exe | fgrep DLL

The output

DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: WS2_32.DLL

shows that the executable is no longer dependent on the Cygwin DLL.