I tried this out today, on both a Raspberry Pi Zero W 2 (quad-core 64-bit ARM Cortex-A53) and my Synology NAS (quad-core Realtek RTD1296).
None of them worked, following exactly the same instructions on either ARM device, as well as using the default place for installation; in both cases, the error is
- Code: Select all
/usr/local/bin/swift: line 12: /opt/swift/bin/swift.bin: No such file or directory
Note that
/usr/local/bin/swift is nothing more than a symbolic link to the script
/opt/swift/bin/swift, which, in turn, sets some crucial environment variables and launches
/opt/swift/bin/swift.bin, which is the actual binary. It identifies correctly as an ARM binary:
- Code: Select all
/opt/swift/bin/swift.bin: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.26, BuildID[sha1]=cafd7c6a69acff7788af4a19e70e6d811ee5c9c6, with debug_info, not stripped
BUT... that's a
32bit binary, and both my devices are
ARM64!!
Fortunately, it's easy to see if your ARM device is able to run executables compiled for 32bits. Under Debian Linux — which should be the case if you use Raspbian or Raspberry Pi OS (its new name) — you can use the small utility
arch-test to figure out which architectures your ARM CPU is able to run:
- Code: Select all
$ sudo apt install arch-test
$ arch-test
arm64
armel
armhf
If
armhf is on the list, you're with luck; that's the 32bit architecture actually used by the
swift binary.
Debian already includes the required cross-compilation tools & libraries for
armhf — everything you need is simply installed with these two packages:
- Code: Select all
$ sudo apt install libc6-armhf-cross
$ sudo apt install libstdc++6-armhf-cross
Now edit
/opt/swift/bin/swift and replace the line containing
LD_LIBRARY_PATH with
- Code: Select all
LD_LIBRARY_PATH=/usr/arm-linux-gnueabihf/lib:/opt/swift/lib:/lib:/usr/lib
This should allow the
swift binary to find most dynamic libraries it needs.
Unfortunately, not all of them; if you look closely at the output of the
file command above, you'll see that the interpreter is loaded with an absolute path,
/lib/ld-linux-armhf.so.3. This library is obviously not there in a 64bit ARM system, so the easiest fix is just to add a symbolic link to the correct place:
- Code: Select all
$ sudo ln -s /usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3 /lib/ld-linux-armhf.so.3
Now you can add the same
LD_LIBRARY_PATH for the license server's own script in
/opt/swift/bin/cepstral-licsrv.
That's it! It certainly works... and compared to the Intel CPU of my Mac, it produces far smaller WAV files... although I'd love to get a 64bit version for ARM, of course!
P.S. Unfortunately, replicating the same result on the Synology NAS is not so easy, since it uses its own proprietary Linux distro. It's heavily inspired by Debian, sure, but it's
not Debian, and doesn't use
any package manager whatsoever. You
can compile things on the Pi and install them on the NAS, or cross-compile them (if you have the sources!), but that's pretty much it. I'd need a very good incentive to have all that trouble