I’ve taken for granted in the past that if I’m on a Raspberry Pi, I’m going to have an easy time of getting software for ARM: it’s all-but the default platform for which ARM software is built, given the prevalence of the board in the marketplace. This isn’t - for now, at least - so true if you’re on a 64-bit OS. In spite of the Pi having a 64-bit processor since the Pi 3, the software ecosystem hasn’t quite caught up to that. This isn’t an issue for things distributed by Debian - all of that ends up in the core repositories and is only an apt install away - but for things distributed in the likes of AppImages or Flatpaks, this poses more of a problem.

I run a 3D printing shop online and use PrusaSlicer for preparing 3D models for printing. I was pleased to see that there is an ARMv7l AppImage available to download and decided to give it a go, having checked that I’d enabled armhf as an architecture using dpkg --add-architecture armhf.

This was not enough to get me to a point where the AppImage would run, with me being told that I was missing ld-linux-armhf.so.3. This made sense, I thought, given that I’d only added the architecture’s to apt’s configuration and not actually installed the packages. I went through some iteration of installing armhf packages before I… just gave up. Having installed zlib1g:armhf, libfuse2:armhf, libstdc++6:armhf, libbz2-1.0:armhf, liblzma5:armhf, libgl1:armhf, libsm6:armhf, libglib2.0-0:armhf, libatk1.0-0:armhf and libgdk-pixbuf-2.0-0:armhf, I realised that I’d probably end up installing an entire armhf userland if I carried on this way.

Rather than committing to the eternal iteration of package installs, I decided to bite the bullet and simply compile the application myself. Fortunately, PrusaSlicer’s build instructions are good and complete, providing an accurate list of dependencies and being based on the assumption of a Debian-based system - making them easy enough to follow on Raspberry Pi OS. I’m lucky enough to be on an 8GB Pi 4, so didn’t run into any issues during the linking step: if I were on a 2GB or 4GB Pi, this would likely be a post about ARM cross-compilation. Fortunately we don’t have to involve ourselves with the Dark Arts here.

The build itself took about an hour, resulting in a PrusaSlicer binary that happily ran. The performance of the 3D viewport in the application isn’t great, but I didn’t expect otherwise. Slicing, however, feels competitive with my Ryzen 9 7950X3D, which surprised me. I know that most slicing algorithms are limited by the performance of a single core and don’t multithread well, but not being frustrated with how long it took was a pleasant treat to receive.

I’ve since found that out that someone builds ARM64 PrusaSlicer AppImages and makes them available to download. Oh well.

In my 3D printing workflow, I also use FreeCAD. This was available directly from the Raspberry Pi OS repositories and - again, surprising to me - was perfectly usable on the Pi. I’d expected frustrating amounts of latency with graphical updates and recalculations, but it’s very useable. This is of course a massively subjective measure of the performance of an application, but it’s ultimately the most important one: I feel like I’m capable of doing the work I need to do on the Pi without feeling like I’m limited by my hardware.