After a bunch of poking and tinkering and swearing, I was finally able to get a VirtualBox instance set up on my laptop to cross compile binaries for the Raspberry Pi. I already had a Backtrack 5 install working so I figured I’d use it for the builds. This probably isn’t the best idea but whatever.

Setting up the cross compiler isn’t that bad. First you need to clone the tools repo from the raspberrypi github account (https://github.com/raspberrypi/tools) into a well accessible location on your build machine. I like putting it in my user directory but some people put it in /usr/local/bcm-gcc/ and others put it under /opt/ somewhere.

git clone https://github.com/raspberrypi/tools

Once that’s done you’re done. All of the tools you need on your system. They’re (probably) in:

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

But you’re not really done yet.

Now, the raspberrypi/tools repo has pretty crappy docs. Hell, they don’t even have README.md in the repo. I guess they expect newcomers to go struggle through a few of the many tutorials on building the tool-chain themselves.

Luckily, the only other piece the cross compiler tools need to actually build things for the Pi is a copy of the Raspberry Pi’s library and header files. They are in /usr/lib/ and /usr/include/ respectively.

People have mentioned setting up the Raspberry Pi for network boot by hosting the Pi’s root filesystem using NFS from their build machine. This is also used to fix SD card corruption when the Pi is overclocked.

However, it may be easier for some people to share the Pi’s root filesystem FROM the Pi itself using NFS. That way, the build machine can mount the Pi’s NFS server and access all of the library and include files directly from the Pi. I stole this idea from a tutorial I found over at cnx-software.com. That tutorial was specifically for building omxplayer but here it is anyways.

Hosting the rootfs from the Pi means that we need to install a few more packages:

sudo apt-get install nfs-kernel-server nfs-common rpcbind

Once that’s done, we need to add the following line to /etc/exports:

/ 192.168.0.0/16(ro,no_root_squash,async,no_subtree_check)

Now, the CNX Software tutorial I linked to (and stole this idea from), sets this export to read write with “rw” as the first export parameter. To build, we shouldn’t need write access. Sure, we won’t be able to copy the compiled binaries back over the the Pi using this NFS share (like I had originally tried doing) but we also don’t run the risk of corrupting the Pi’s SD card. Better safe the sorry in my opinion.

Once that’s done, you’ve gotta configure and start rpcbind, then start the NFS server itself and update the exports to pull in the root share you just added to the config file. Do that with:

sudo dpkg-reconfigure rpcbind
sudo /etc/init.d/rpcbind restart
sudo /etc/init.d/nfs-kernel-server restart
sudo exportfs -a

Oh, and also, to get the servers running correctly on startup, do:

sudo update-rc.d rpcbind enable
sudo update-rc.d nfs-common enable

which would add those services to the default boot.

Then you should be in business! Mount the Pi’s root filesystem using an NFS client on your build machine, point your includes at the correct path in the NFS share, and build away!

Of course I’m leaving a bit out, but at least I’ve shared the idea…