My previous Raspberry Pi related blog post was about running the Eclipse Orion server. This time I wanted to run a more demanding Eclipse RCP (Rich Client Platform) application and decided to use the better performing hard float “Wheezy” distribution of Raspbian.

As Java 7 is not available in the required flavour I also have to use the early access version of Java 8. The procedure of installing both of these is pretty identical to what I described in my previous post, so I’m not wasting time on documenting it. You’re probably able to figure it out.

Now, Eclipse RCP applications are, as I think you already know; Java GUI applications with native widgets, OSGi and what not. So JNI binaries for the platform have to be present. In this case binaries for 32-bit ARM (v6 little endian) Linux using the GTK windowing system. The crux of this experiment is that these binaries are not readily available. The source code must possibly be ported and at least compiled for the architecture in question before it can be used in an RCP application. Also, for the sake of sanity, it would be better if everything was available in a Equinox p2 repository to use as target platform.

Building SWT native libraries

This part describes how to build the native libraries for Raspberry Pi. However there is no real reason why everyone should have to do this – so you may just jump to the last section if you want to get started on writing applications.

Now, the Common Build Infrastructure (CBI) does offer an option to build natives on preconfigured hosts – I did not explore that option. I suspect that it should be fairly straightforward once one figure out where to do the configuration. Meanwhile this part is done manually.

Follow the instructions for using SWT from Git. Import the org.eclipse.swt project, make sure you change the .classpath_gtk to .classpath and built it. This should result in a new bin folder which contains source code for the SWT native libraries.

I grasped from the SWT documentation that the SWT JNI libraries are not simply cross compiled, so we would probably be better off just building them on the Raspberry Pi. Easy does it. In order to do so we must install a few required development packages:

sudo apt-get install libgtk2.0-dev
sudo apt-get install libx11-dev
sudo apt-get install libxtst-dev
sudo apt-get install libgl1-mesa-dev
sudo apt-get install libglu1-mesa-dev

This will just give you the minimum of SWT libraries – there are more that can be built.

Now, copy the entire org.eclipse.swt project from your host to the Raspberry Pi. Then on the Pi execute:

cd eclipse.platform.swt/bundles/org.eclipse.swt/bin/library/
pi@raspberrypi ~ $ sh build.sh

This will compile the SWT JNI libraries for the ARM v6 little endian architecture. After a while we should have a few static libraries available:

find . -name *.so
./libswt-glx-gtk-4331.so
./libswt-webkit-gtk-4331.so
./libswt-atk-gtk-4331.so
./libswt-cairo-gtk-4331.so
./libswt-pi-gtk-4331.so
./libswt-gtk-4331.so

These are the files that are used by Java to render Gtk widgets when running SWT on a Raspberry Pi. You could create a new fragment bundle in eclipse.platform.swt.binaries named org.eclipse.swt.gtk.linux.armv6l, place the binaries in there and rig it all up.

Building the Equinox launcher

The Equinox launcher is not really required for this experiment. However it does make launching Eclipse based applications much easier as we get a proper native executable to use. The problem is that CBI appears to expect a launcher to be present for all architectures when building. So let’s indulge it.

Like the SWT there appears to be some rigging in place to do the native building on preconfigured hosts. However this part is even more straightforward than for SWT.

I’ve already done the work with adding the armv6l bundle so the only thing that must be done is to build the native code.

git clone https://github.com/turesheim/rt.equinox.framework.git
sh rt.equinox.framework/bundles/org.eclipse.equinox.executable/library/gtk/build.sh

You should now have one eclipse executable and one eclipse_1504.so that must be placed in certain locations in the rt.equinox.binaries project. Again – I’ve already done that. You’ll find everything over at GitHub.

Building Eclipse

Now we need to build the Eclipse Platform in order to get a p2 repository to use as target repository. You’ll also get the Eclipse SDK product builds for various platforms. I’ve written a script that will do just that. It uses a customized version of eclipse.platform.releng.aggregator, with the addition of a few other bundles with the ARMv6 support. (The wonders of git submodule is at play here).

#!/bin/bash

# Use a particular maven repository
LOCAL_REPO=$(pwd)/localRepo

# Make sure we have enough memory for Maven
export MAVEN_OPTS=-Xmx2048m

# Clone the Eclipse platform
if [ ! -f ./eclipse.platform.releng.aggregator/.gitmodules ];
then

  git clone --recurse-submodules 
    https://github.com/turesheim/eclipse.platform.releng.aggregator.git
  pushd eclipse.platform.releng.aggregator

else

  pushd eclipse.platform.releng.aggregator
  # Clean, reset and update to the latest version
  git clean -f -d
  git reset --hard HEAD
  # Remove artifacts from previous build
  git submodule foreach git clean -f -d
  git submodule foreach git reset --hard HEAD

fi

# Lay the ground
mvn -f eclipse-platform-parent/pom.xml clean install 
  -Dmaven.repo.local=$LOCAL_REPO
# Do the actual build
mvn -e clean install 
  -Pno-bree-libs 
  -Dmaven.test.skip=true 
  -Dtycho.version=0.18.0-SNAPSHOT 
  -Dtycho-extras.version=0.18.0-SNAPSHOT 
  -Dmaven.repo.local=$LOCAL_REPO

popd

Execute this script and after a few hours you should now have an Eclipse SDK in eclipse.platform.releng.aggregator/eclipse.platform.releng.tychoeclipsebuilder/sdk/target/products you should now find org.eclipse.sdk.ide-linux.gtk.armv6l.tar.gz. The target platform is at eclipse.platform.releng.aggregator/eclipse.platform.releng.tychoeclipsebuilder/rcp.sdk/target/repository.

I decided to try it all out by running the one RCP application I have ready, the Eclipse SDK. It is actually barely usable – but you could do small projects. I would not recommend doing your development in this way though, but a far less demanding RCP application would probably work OK. That’s what the target platform repository is for.

Have fun!