Spotify connect plugin cannot change to different track

Ok, that cross-build did not work, at some point along the way the alsa-sys package refused to build without additional effort to make pkg-config happy for cross-compiling, probably since it links against a system library. Since I didn’t want to go there, I instead tried compiling on a rpi zero (which should compile for armv6 and also run on armv7 I hope), and compile using the Debian-supplied rustc on Buster (which I assume is also armv6 since it runs on the zero too).

On the rpi zero, I had to re-run rustup-init, since the files I previously downloaded on the rpi3 did not run (segfault). After this, the build ran fine, though it did take *long* (In total probably somewhere between 4-8 hours, at some points it was crunching on a single package for so long it seemed to be stuck, but it would just be slow it seems).

On buster, using the Rasbpian-supplied rustc package, things compiled faster (since this could run on a rpi3), but took a lot more effort to get it to work (or at least to figure out a workaround). I ran into problems compiling the typenums rust package, which I traced back to a misoptimization in the LLVM backend (see this bug I reported for details). Until that bug is fixed in Raspbian, a workaround is needed. Fortunately, it is simple, just install libllvm7 from Debian rather than Raspbian:

$ wget http://ftp.de.debian.org/debian/pool/main/l/llvm-toolchain-7/libllvm7_7.0.1-8_armhf.deb
$ sudo dpkg -i libllvm7_7.0.1-8_armhf.deb

This is only needed on the rpi that compiles librespot, not for running.

The architecture used (in both approaches) is apparently arm-unknown-linux-gnueabihf, so that’s slightly different from what I manually picked above.

Both approaches resulted in a binary that works on both zero and rpi3, and did not have the track-changing problem I started this for. The librespot compiled on the rpi zero on Stretch also worked on Buster, but the one compiled on Buster did *not* work on stretch (due to the older libc version). So, if you want to support a newer spotify plugin also on existing stretch installs, it must be compiled on older hardware to get rustup to build for the right architecture. Or maybe investigate cross-compiling after all (which might have been less work in hindsight, but I’m not going to *also* dive into that :-p).

Building a toolchain to compile downwards compatible on the PI 4 with buster might take me much longer than just using the PI 3.

If you compile on the rpi3 (with rustc from rustup), that does mean the binary will not run on the rpi zero, right? Any plans to update that binary as well?

One alternative that sprung to mind would be to combine both of my approaches by installing the rustc package from Buster on a Stretch system. If that works dependency-wise (which might be tricky), that will probably result in a binary that works on Stretch and Buster.

Also, if you’re thinking of cross-compiling from a pi4, it might be more interesting to look at cross-compiling this on a regular x86 system, which could be a *lot* faster. There’s probably some tutorials for this, though I haven’t investigated yet.

In the meanwhile, the problem with libllvm7 in Buster seems to be figured out (maybe even fixed already, haven’t checked). See https://github.com/rust-lang/rust/issues/60019#issuecomment-512073512