Monthly Archives: January 2008

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 www.eclipse.org 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
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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
http://download.eclipse.org/tools/cdt/releases/europa

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

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.
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.3</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>1.3.1</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1</version>
<scope>compile</scope>
</dependency>

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:
<testResources>
<testResource>
<directory>src/test/config</directory>
<includes>
<include>log4j.xml</include>
</includes>
</testResource>
</testResources>

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

Description from the homepage: “ZGRViewer is a 2.5D graph visualizer implemented in Java and based upon the Zoomable Visual Transformation Machine. It is specifically aimed at displaying graphs expressed using the DOT language from AT&T GraphViz and processed by programs dot, neato or others such as twopi.”

Occasionally I have to deal with large graphs for some recursive automatons in the context of a dynamic programming algorithm. My automaton class is able to return a dot-style representation which describes the finite automaton, and it turns out that ZGRViewer excels in handling such large graphs by providing smooth zooming and easy navigation in the visualized graph. I found that because of the use of SVG it is much less memory consuming than, say, converting it to PNG bitmap graphics.

Here is a screenshot of ZGRViewer showing my DOT file opened with neato. Visit the ZGRViewer homepage for more screenshots and videos.

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
PATH=/cygdrive/c/MinGW/bin:$PATH

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.