Raspberry Pi Raspbian cross compiler toolchains on 64bit Linux

A while back I setup Eclipse C++ on Ubuntu to cross compile some ARM Assembly (see here). Last time I set up the Raspberry Pi tools on Ubuntu I was using a 32bit install. More recently I installed a 64bit version of Kubuntu, and so was retracing my steps to get set up again.

It might be obvious if you’re more familiar with gcc and cross compiler toolchains, but in the Raspberry Pi tools project there’s 32 bit and 64 bit versions of the tools. Trying to use the 32 bit versions on 64 bit Linux does not work. Rather than some useful error though, trying to execute any of the 32bit versions from a shell gives a rather un-useful ‘No such file or directory’ error.

Referring back to my original Eclipse C++ setup instructions, if you’re running Eclipse on 32bit Linux then you want to point to the tools here:

~/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin

Otherwise point to the 64bit version here:

~/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin

Cross-compiling ARM ASM on the Mac for the Raspberry Pi

I’ve posted recently about my experience learning some ARM assembly, and in particular, attempting to develop a simple sorting algorithm. Initially I had just been using Atom and TextMate editors on my Mac and then ftp’ing the source over to the Pi to compile and run, but I had got to a point where I realized this wasn’t going to cut it for working on anything slightly larger, so I started looking at getting Eclipse C++ working with cross compiler toolchains (cross compiling allows you to compile code on one hardware architecture type to run on another)

I actually looked into getting this working on Windows several months back, but I hadn’t used it or pursued it any further, so rather than trying to retrace my steps, I started again from scratch (I also wanted to get it working on my Mac rather than on Windows).

The First Attempt – Compiling in Eclipse C++ on the Mac

Skipping a few steps to get to the more interesting details, assuming Eclipse for C++ is already downloaded and installed along with the GNU toolchain for ARM, here’s what I got building my project for the first time:

 11:54:51 **** Build of configuration arm cross compile for project ASMCrossCompile ****
 make all
 Building file: ../test.S
 Invoking: Cross GCC Assembler
 /Applications/EclipseIDEs/gcc-arm-none-eabi-4_9-2015q2/bin/arm-none-eabi-as-o "test.o" "../test.S"
 Finished building: ../test.S
 Building target: ASMCrossCompile
 Invoking: Cross GCC Linker
 /Applications/EclipseIDEs/gcc-arm-none-eabi-4_9-2015q2/bin/arm-none-eabi-gcc-L/Applications/EclipseIDEs/gcc-arm-none-eabi-4_9-2015q2/arm-none-eabi/lib -o "ASMCrossCompile" ./test.o
 /Applications/EclipseIDEs/gcc-arm-none-eabi-4_9-2015q2/arm-none-eabi/lib/libc.a(lib_a-exit.o): In function `exit':
 exit.c:(.text.exit+0x2c): undefined reference to `_exit'
 collect2: error: ld returned 1 exit status
 make: *** [ASMCrossCompile] Error 1

This error “undefined reference to `_exit'” is described in this SO post here:
http://stackoverflow.com/questions/19419782/exit-c-text0x18-undefined-reference-to-exit-when-using-arm-none-eabi-gcc

This issue is apparently directly related to cross compiling on a different hardware architecture, and the solution is to add the –specs=nosys.specs option to the loader config. I added this in Eclipse in project properties, C/C++ Build/Settings/Cross GCC Linker and added into the Expert Settings Command Line Pattern and this fixed this issue.

Transferring the Executable to the Pi

In Eclipse C++, in the Run Configuration settings you can select ‘New Connection’ and configure a ssh connection to your Pi. You need to also set a full path on the Pi for where the file is going to be dropped.

At this point I get this error: “Error during upload : File system input or output error”. Executing the file on the Pi itself I get a Seg Fault.

Searching around, the general suggestion seems to run ‘file’ against the executable to check that it was compiled and linked against the right architecture.

For my newly cross compile file, I get this:

pi@raspberrypi~/asm $ file ASMCrossCompile
ASMCrossCompile: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped

And for an executable running correctly on the Pi I get this:

pi@raspberrypi~/asm $ file loopNums
loopNums: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x91189f47c9216e8d281238cba56b56042bcf8e6b, not stripped

Ok, so clearly I’m close but not there yet.

From other posts like this one (some of the key screenshots in this one seem missing) and this one, it seems it far easier and more direct to use the ready to go compiler crosschain from the RaspberryPi project available from github here  (and not just a more generic toolchain for ARM processors but not specifically for the Pi and/or Raspbian). This is compiled for Linux, so following the tips in the prior two articles, this was my next attempt.

Second Attempt: Eclipse C++ plus Raspberry Pi Tools toolchain … on Ubuntu … on VirtualBox … on the Mac

Clone the Tools.git project from the above github project url.

Creating a C Project

Create a new C Project, select the defaults per this screenshot:Create Project

Next through to this dialog – point to where you cloned the Raspberry Pi Tools source:


Configure toolchain path

 

  • Set the compiler prefix to:arm-linux-gnueabihf-
  • Set the path to /rpi_tools_download_dir/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin

To build the project, select Build and Build All.

Done.

You should see a Binaries entry in your Project Explorer tree view appear.

To deploy the code over to the Pi we can set up the Run Configuration selecting the Remote Application option again, use ssh and point it to your Pi.

Now I’m still getting the same generic input/output error that I was before, so I Input/Output errorssh’d over to the Pi to take a look at the new file that had appeared over there, and noticed that it wasn’t executable, so on the Remote Execution step you still need to do a chmod +x on it.

Doing a file on it though shows settings that are the same as what I had on executables compiled and linked on the Pi, so now we’re looking good:

pi@raspberrypi ~/asm $ file asm_test
asm_test: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x9f6ace58f6cc2d036ea113e69dc40a5f7fc5521d, not stripped

Now we’re getting somewhere!

A quick hello world calling syscall 4 to do write to the console:

.global main
 main:
 MOV R7, #4 @ Syscall 4 = write to screen
 MOV R0, #1 @ 1=stdout: move 1 to R0
 MOV R2, #13 @ length of string to R2
 LDR R1, =string
 SWI 0
 BX lr
 string:
 .asciz "hello world!\n"

Adding the chmod seems to get us an executable on the Pi side, but still get the i/o error.

However! ssh’ing over to Pi and executing the newly transferred file:

pi@raspberrypi ~/asm $ ./asm_test
hello world!

Success! I can now use Eclipse on my Mac to develop asm for the Pi! (Although having to run it on Ubuntu on VirtualBox on the Mac, but I can live with that 🙂

Eclipse error: Access restriction: The type ‘xyz’ is not API

Eclipse has some pretty bizarre error messages that really don’t tell you exactly what the error is or how to fix it. This weekend I saw this one for example:

Access restriction: The type 'xyz' is not API (restriction on required library ...)

A quick Google told me what this actually means is that I have a line of code using a JDK API that is not in the currently selected runtime for the current project, but does exist in other available runtimes.

For example, when setting up a project with a Maven pom.xml, if you don’t explicitly specify what JVM version you want for the project, you get Java 5 by default.

There’s a couple of different ways to change the JVM version using Maven, but the approach I prefer is by adding properties (because it’s more concise than configuring the Maven compiler plugin):

<properties>
    <maven.compiler.target>1.8</maven.compiler.target>
    <maven.compiler.source>1.8</maven.compiler.source>
</properties>

Alternatively if you’re not using Maven, just change the JRE System Library in the project settings on the Java Build Path/Libraries tab (remove the one that’s currently there and add the version that does have the APIs that you’re using, most likely a later version).