These are the steps for setting up a toolchain and SDK to cross compile GNU Linux for the Beagleboard ver. C4 (OMAP 3530).  The host is Ubuntu 10.04.  The toolchain is then used to cross compile the Codelite package.


Start by making a filesystem and SDK with Narcissus.  Be sure to include the option for the toolchain and X11 with xfce4.  Save and extract the SDK to the root / of the partition.
mark@ubuntu:~$ cd /
mark@ubuntu:/$ sudo tar -xfv /home/mark/Downloads/angstrom-SDK.tar.gz

This should create the folders:

I made the following changes to the environment-setup script located in /usr/local/angstrom/arm/../environment-setup

-export PKG_CONFIG_PATH=$SDK_PATH/$TARGET_SYS${libdir}pkgconfig
+export PKG_CONFIG_PATH=$SDK_PATH/$TARGET_SYS/usr/lib/pkgconfig

alias gcc=”arm-angstrom-linux-gnueabi-gcc”
alias g++=”arm-angstrom-linux-gnueabi-g++”
alias as=”arm-angstrom-linux-gnueabi-as”
alias strip=”arm-angstrom-linux-gnueabi-strip”
alias ld=”arm-angstrom-linux-gnueabi-ld”

CORE_NUM=`cat /proc/cpuinfo | grep processor | wc -l`
alias make=”make -j$CORE_NUM”

Beagleboard rootfs install

Save the file system tar.gz that Narcissus generated and untar it to the SD partition.  There are a number of ways to boot the Beagleboard and the particulars of this step are not included.  Once Angstrom has booted, login as root and issue the following commands.

root:~# opkg install angstrom-x11-base-depends
root:~# startxfce4

Cross Compiling

The Codelite project requires the wxWidgets GTK libraries.
Get the wxWidgets source package from
Untar and cd to the root of the wxWidgets folder

Prepare the shell for cross compiling by running the environment-setup script.  Don’t forget the period before /usr/…

wxWidgets-2.9.1$ . /usr/local/angstrom/arm/environment-setup
wxWidgets-2.9.1$ opkg-target update
wxWidgets-2.9.1$ mkdir build_gtk
wxWidgets-2.9.1$ cd build_gtk

Build wxWidgets with the Narcissus SDK:

build_gtk$ ../configure –enable-unicode –enable-debug –host=arm-angstrom-linux-gnueabi –with-gtk
build_gtk$ make -j2
build_gtk$ sudo make install

Build Codelite with Narcissus SDK:
Downloads$ svn co codelite
Downloads$ cd codelite/
codelite$ ./configure –host=arm-angstrom-linux-gnueabi
codelite$ make -j2

Install on Beagleboard

Copy the wxWidgets libraries labled ‘’ to /usr/local/lib/ of the Beagleboard rootfs.  Also copy the codelite folder to a location on the Beagleboards rootfs.

Boot the Beagleboard and issue the following commands as root user.
root:~# echo “/usr/local/lib” >> /etc/
root:~# ldconfig

You can either edit the Makefile and change the paths or delete it and reconfigure a new one.  I think it still needs to be edited even after a reconfigure iirc.

root:~# cd codelite

root:~/codelite# ./configure
root:~/codelite# make install

Codelite should now be up and running on the Beagleboard.




I transformed a simple helloworld C program into C++ classes.  I was able to match up one-to-one the C generated assembly to a C++ equivalent.  In this example, the benefit of using C++ code is limited to namespaces.  Hopefully you can see how the usage of C++ namespaces improves readability and assists in minimizing coding errors.  Most of the C code projects end up becoming so sloppy and full of pitfalls.  Using C++ allows your code base to be small and manageable across the spectrum of projects.  The code and makefile for the project are located here.  The project was compiled with the msp430gcc toolchain on a Ubuntu host.

Setting Up

Instructions for building the msp430 gnu toolchain are at  Many sites claimed to setup the Launchpad for debugging with gdb and eclipse, but none worked for me. I was able to set up debugging in eclipse as follows.  If you don’t already have it, install the Zylin Embedded CDT plugin.  I have v14.15.1 installed in Galileo (Eclipse).  It’s assumed that you have the drivers properly configured for mspdebug and that you can communicate with the Launchpad using the mspdebug command line.

Run-> External Tools–> External Tools Configuration

Select the “Program” in the tree control of the left pane and then click the icon for “New Launch Configuration”

Fill in the dialog as shown.





Run->Debug Configurations

Create a new configuration under the tree heading –> Zylin Embedded Debug (Native)

Fill in the ‘main’ tab with the project name and point to the .elf of the application that you are going to debug.

Fill in the ‘debugger’ tab with the location of msp430-gdb.  For me this was “/opt/msp430-gcc-4.4.5/bin/msp430-gdb”.  The command line is empty.

Fill in the ‘commands’ tab with the following in the ‘initial’ section and a “continue” in the ‘run’ section:

set remoteaddresssize 64
set remotetimeout 999999
target remote localhost:2000

Code Differences

So now you have a makefile for C++ projects and a couple of basic MSP430 objects.

Notice the destructors are not virtual functions in the example code.  It’s unlikely you’ll be deleting static objects, so you can eliminate a bunch of unneeded code by declaring them this way. Since they will never be called, more code space is saved by removing them entirely.  My preferred solution would be editing the linker script and discarding the destructors section.

I tried to get as close to the original C generated assembly as I could.  This required some reworking of the timer header.  The functionality of the object is changed, but it’s a closer match to the original C code with only an 8 word difference.  The startup assembly script would need modification to make the code match up entirely.  Here are the listings for the generated assembly, C version and C++ version.

There is a great series on using the gnu tools for bare metal programming and C++ at




© 2016 engine12