All posts by Dirk Raffel

Dirk is a freelance senior software consultant/engineer/architect located in Berlin, Germany. His key expertise includes embedded and system programming in areas of public transport, railway technology, automotive/traffic telematics. Read more...

ClearCase and text files with long lines of text

Note 2 myself just in case I’ll stumble into this again:

I’ve tried to add a javascript file (jquery-1.3.2.min.js) to clearcase, and got the following response:

jquery-1.3.2.min.js is not a 'text file': it contains a line exceeding 8000 bytes. Use a different type manager (such as compressed file).
Type manager "text_file_delta" failed create_version operation.

Huh? Anyway, this can be solved by

$ cleartool chtype -nc compressed_file jquery-1.3.2.min.js

Change version manager and reconstruct all version for "jquery-1.3.2.min.js"? [no] y
Changed type of element "jquery-1.3.2.min.js" to "compressed_file".

Afterwards, the file can be checked in without problems.

A boost::statechart example

How would you transform a statechart (David Harel statechart, or UML state diagram if you like) into executable C++ code? You can use one of the many free and commercial tools that are able to generate very efficient C or C++ code from statecharts, but you can also do so without needing such a tool: you might also consider using the Boost statechart library.

For a simple example, consider the following scenario :
Assume a controller has one push button switch wired to an input, and one lamp wired to an output. The first time the button is pressed the lamp must come on. The next time the button is pressed, the lamp must turn off. On the next press the lamp comes on, etc. etc. Don’t forget to allow for the button to be released before it is pressed again.

Sounds easy, doesn’t it? However, often the required behavior is not so trivial (when we’d like to restore previous state, or when reactions depend on the active state in many orthogonal regions). In this case, I typically use a statechart design. IMO this method scales up very well to large and complicated systems.

A possible solution for our example looks like this: We have two orthogonal regions, one region with two states for button pressed/released and another region with light on/off.
The statechart

As with many of the Boost libraries, boost::statechart is header-only and uses templates quite heavily. In general, the documentation is quite good, so don’t be afraid to read it. There is also an excellent tutorial for those just starting out, with plenty of examples.

So without further ado, here’s the source code that implements the statechart from above:

#include <boost/statechart/event.hpp>
#include <boost/statechart/state_machine.hpp>
#include <boost/statechart/simple_state.hpp>
#include <boost/statechart/state.hpp>
#include <boost/statechart/transition.hpp>
#include <boost/mpl/list.hpp>
#include <iostream>

using namespace std;

namespace sc = boost::statechart;
namespace mpl = boost::mpl;

struct EvPressButton : sc::event<EvPressButton>
    cout << "Button is pressed" << endl;

struct EvReleaseButton : sc::event<EvReleaseButton>
    cout << "Button is released" << endl;

struct EvToggleLight : sc::event<EvToggleLight> {};

struct Active;
struct Switch : sc::state_machine<Switch, Active> {};

struct ButtonReleased;
struct ButtonPressed;
struct LightOff;
struct LightOn;

struct Active: sc::simple_state<Active, Switch,mpl::list<ButtonReleased, LightOff> > {};
struct ButtonPressed : sc::state<ButtonPressed, Active::orthogonal<0> >
  typedef sc::transition<EvReleaseButton, ButtonReleased> reactions;
  ButtonPressed(my_context ctx) : my_base(ctx)

struct ButtonReleased : sc::simple_state<ButtonReleased, Active::orthogonal<0> >
  typedef sc::transition<EvPressButton, ButtonPressed> reactions;

struct LightOff : sc::simple_state<LightOff, Active::orthogonal<1> >
  typedef sc::transition<EvToggleLight, LightOn> reactions;
    cout << "Light is off" << endl;

struct LightOn : sc::simple_state<LightOn, Active::orthogonal<1> >
  typedef sc::transition<EvToggleLight, LightOff> reactions;
    cout << "Light is on" << endl;

int main()
  Switch sw;
  for (int i = 0; i < 5; i++)
  return 0;

The output:

Light is off
Button is pressed
Light is on
Button is released
Button is pressed
Light is off
Button is released
Button is pressed
Light is on
Button is released
Button is pressed
Light is off
Button is released
Button is pressed
Light is on
Button is released

Which looks about right, I think. 🙂

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. 🙂