Run x86_64 (Intel/AMD) AppImages on ARM (e.g., Raspberry Pi 5)

[probonopd]

Every so often, a technology comes along that truly blows your mind.

Today is such a day for me.

I am currently playing with the new Raspberry Pi 5 which is using the ARM 64-bit architecture (a.k.a. aarch64, arm64). In order to be able to run some Windows binaries with WINE, I installed the box64 emulator.

Curious what would happen if you try to run a x86_64 (Intel/AMD) AppImage on this ARM 64-bit with box64, I launched the first AppImage I could find. And to my big suprise, it not only worked flawlessly, but even in acceptable speed.

Turns out that box64 can happily mix Intel/AMD and ARM binaries and libraries:

user@raspberrypi:~ $ Downloads/Muview2-x86_64.AppImage 
Dynarec for ARM64, with extension: ASIMD AES CRC32 PMULL ATOMICS PageSize:4096 Running on Cortex-A76 with 4 Cores
Params database has 32 entries
Box64 with Dynarec v0.2.5 54be0c0d built on Nov 18 2023 06:16:27
BOX64: Didn't detect 48bits of address space, considering it's 39bits
Counted 50 Env var
BOX64 LIB PATH: ./:lib/:lib64/:x86_64/:bin64/:libs64/:/lib/x86_64-linux-gnu/:/usr/lib/x86_64-linux-gnu/
BOX64 BIN PATH: ./:bin/:/home/user/.local/bin/:/usr/local/sbin/:/usr/local/bin/:/usr/sbin/:/usr/bin/:/sbin/:/bin/:/usr/local/games/:/usr/games/
Looking for Downloads/Muview2-x86_64.AppImage
Rename process to "Muview2-x86_64.AppImage"
Using native(wrapped) libdl.so.2
Using native(wrapped) libpthread.so.0
Using native(wrapped) libz.so.1
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux-x86-64.so.2
Using native(wrapped) libutil.so.1
Using native(wrapped) librt.so.1
Using native(wrapped) libfuse.so.2
Dynarec for ARM64, with extension: ASIMD AES CRC32 PMULL ATOMICS PageSize:4096 Running on Cortex-A76 with 4 Cores
Params database has 32 entries
Box64 with Dynarec v0.2.5 54be0c0d built on Nov 18 2023 06:16:27
BOX64: Didn't detect 48bits of address space, considering it's 39bits
Counted 54 Env var
BOX64 LIB PATH: ./:lib/:lib64/:x86_64/:bin64/:libs64/:/lib/x86_64-linux-gnu/:/usr/lib/x86_64-linux-gnu/
BOX64 BIN PATH: ./:bin/:/home/user/.local/bin/:/usr/local/sbin/:/usr/local/bin/:/usr/sbin/:/usr/bin/:/sbin/:/bin/:/usr/local/games/:/usr/games/
Looking for /tmp/.mount_MuviewjxAYCJ/AppRun
Rename process to "muview"
Using emulated /tmp/.mount_MuviewjxAYCJ/lib/libQt5OpenGL.so.5
Using emulated /tmp/.mount_MuviewjxAYCJ/lib/libQt5Widgets.so.5
Using emulated /tmp/.mount_MuviewjxAYCJ/lib/libQt5Gui.so.5
Using emulated /tmp/.mount_MuviewjxAYCJ/lib/libQt5Core.so.5
Using native(wrapped) libGL.so.1
...

What does this mean in practice? You can use box64 to run AppImages that were not made for ARM. Of course it is still more efficient to run native ones, but in the meantime... this is truly great!

Best of all, if box64 is installed, this works seamlessly - just double click AppImages as usual.

Mind blown.

[TheAssassin]

How does it perform in comparison to QEMU, another emulator that provides you with a way to run stuff that was not built for ARM?

Please note that you may have to use a Docker container as a base environment; in comparison to box64 QEMU does not ship a complete runtime that includes a loader and the basic libraries. A static binary will work without Docker, though.

[probonopd]

Haven't tried this in QEMU, wouldn't have assumed that QEMU can mix and match architectures?

[TheAssassin]

Define "mix and match". QEMU emulates all instructions in a binary one by one. I would assume box64 does the same in the worst case, but they promise some improvement with that compiler they're using. That's why I'm curious.

[probonopd]

Define "mix and match".

Using an x86_64 AppImage on aarch64 despite the fact that not all libraries are in the AppImage, hence foreign-architecture binary and some foreign-architecture libraries run on top of native-architecture core libraries. Maybe it's just me, but I find this amazing.

[TheAssassin]

This reminds me a lot of rosetta2 on the macOS ARM (M1/M2) platform that also provides a basically seamless way to run AMD64 binaries on ARM. rosetta2 performs quite good for an emulator (as far as I know it is accelerated by the hardware, though), so I wonder how this performs in comparison. It might provide a good way for people to run AMD64 AppImages on ARM until a native build is available. In that case, it should go into https://docs.appimage.org.

[probonopd]

Don't know about a performance comparison with Rosetta 2 since I don't have an ARM-based Mac to test this on. I'd say "your mileage varies" but for simple applications it is definitely usable on a Raspberry Pi 4 (and better than not being able to run an application in any case).