Update: The Raspberry Pi Mathematica executables now rely on the existence of
Raspberry Pi specific graphics interfaces being present in /dev. As a result,
this method no longer works for recent releases.
I recently got a Pinebook to use as my primary laptop after my last one died. It’s a lightweight little laptop made by Pine64, a community of open source hardware hackers. To keep things cheap, low-power and open, the Pinebook’s processor is an Allwinner Cortex-A53 64-bit ARM processor. Not a big deal; I’ve used Arch Linux ARM (ALARM) before when I had an ASUS Chromebook, and the open and documented bootloader on the Pinebook made it easy to get the aarch64 architecture ALARM distribution running.
I use Mathematica quite a bit in my research, and as proprietary software you can’t build it for a new architecture. Fortunately, Wolfram has a build of Mathematica for ARM intended for the Raspberry Pi, which I was familiar with from my Chromebook days. Unfortunately, they do not have an arm64 build: it’s meant for armv6h. To run it, you need a processor and kernel that can interpret armhf binaries and the system libraries Mathematica needs for the armhf architecture. The following is the cleanest way I found to do it within Arch.
If you have a Pinebook you already have a CPU that can execute armhf
instructions, so that’s a start. Now we have to make sure our kernel will
understand and allow them. The packaged ALARM kernels for aarch64 don’t have
the backwards compatibility features turned on by default, but that’s not a big
deal since they have to be patched for the Pinebook anyway. Check
/proc/config.gz to make sure CONFIG_COMPAT, CONFIG_ARMV8_DEPRECATED, and
CONFIG_COMPAT_BINFMT_ELF are enabled. The first option provides the
compatibility layer at all, the second ensures several armhf instructions used
by Mathematica are actually supported, and the third ensures armhf binaries can
be easily run in userspace. If these are set, congrats! If not, you need to
recompile your kernel.
Ensuring the correct shared libraries are in the places Mathematica expects
them has the potential to be the most difficult part. For most things
Mathematica will check the LD_LIBRARY_PATH, but wants
/lib/ld-linux-armhf.so.3 to exist and point to an appropriate glibc library.
Many distributions have multilib repositories that can be activated by changing
a configuration file. ALARM has no such thing, but it does have repositories
built for other architectures. Rather than mess with hand-rolled multilib
packages that would probably lead to dependency hell, we’ll take advantage of
Arch’s small size and install an entire armv6h distribution in a chroot.
Make sure you have arch-install-scripts installed, and copy your
pacman.conf to /tmp/pacman.conf. Edit the temporary file and replace the
architecture with armv6h. You can then run
# pacstrap -C /tmp/pacman.conf /armv6h base fontconfig glu libpng pixman portaudio qt5-baseto install an entire ALARM distribution for the new architecture to /armv6h,
along with several libraries Mathematica will look for. Follow the Arch install
guide to set up the locale, and perhaps install a terminfo package.
You now need symlinks for the libraries. I’ve written a package
that symlinks the glibc library to the right place, and links /armv6h/usr/lib
to /usr/libv6h (my later wolfram-engine and wolframscript packages depend on
the libraries being available in /usr/libv6h). The package might be overkill,
but I don’t like files the package manager doesn’t know about floating around
my system. The nice part about this setup is that for basically no work we get
the libraries we need, and all the resulting files are managed by one of the
pacmans (pacmen?). The armv6h libraries can be easily updated by chrooting in
and running pacman as usual.
We can finally arrive at installing Mathematica. I’ve written PKGBUILDs for
wolfram-engine and wolframscript that source
the Wolfram-provided deb files and packages them for Arch. The package modifies
the included “Executables”, which are actually scripts that set up sane
enviornments for the binary executables. First, they have some logic that
attempts to deterine the system architecture and will fail if they can’t
recognize it. The patches add a condition for aarch64. Second, their
LD_LIBRARY_PATH variables need to prefer /usr/libv6h to /usr/lib, and the
patches ensure this.
Once built and installed, you should be able to type math at the command line
and have the Wolfram engine launch! You’ll need a software license, but for the
scripting language and command line interface there are free licenses
available. I found that the online activation wasn’t working
(probably could be fixed by installing openssl-1.0 in the chroot), but was
able to register by generating a password on the user portal.