Spotifyd Dependency Issue

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

  • DietPi version | G_DIETPI_VERSION_CORE=9
    G_DIETPI_VERSION_SUB=20
    G_DIETPI_VERSION_RC=1
  • Distro version | Trixie
  • Kernel version | 6.12.58-current-sunxi #1 SMP Thu Nov 13 20:34:41 UTC 2025 armv7l GNU/Linux
  • Architecture | armhf
  • SBC model | Nanopi Neo
  • Power supply used | 5V 3A
  • SD card used | sandisk

Additional Information (if applicable)

  • Software title | Spotifyd
  • Was the software title installed freshly or updated/migrated? - Fresh installation

Steps to reproduce

  1. Fresh installation
  2. use dietpi-software
  3. select and install spotifyd

Expected behaviour

  • edit /mnt/dietpi_userdata//spotifyd/spotifyd.conf with necessary details
  • systemctl restart spotifyd
  • spotifyd should run

Actual behaviour

/opt/spotifyd/spotifyd: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

LibSSL1.1 is not available anymore in Debian Trixie but spotifyd depends on it. Last it was available on Debian Bullseye I guess.

root@DietPi7:~/spotifyd# /opt/spotifyd/spotifyd
/opt/spotifyd/spotifyd: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

So I build a version statically linked against OpenSSL3 and tested it on my RPi 3:

root@DietPi7:~# uname -a
Linux DietPi7 6.12.47+rpt-rpi-v7 #1 SMP Raspbian 1:6.12.47-1+rpt1 (2025-09-16) armv7l GNU/Linux

root@DietPi7:~# ./spotifyd --version
spotifyd 0.4.2

root@DietPi7:~# ./spotifyd --no-daemon
[INFO] No config file specified. Running with default values
[INFO] Using software volume controller.
[INFO] Mixing with softvol and volume control: Log(60.0)
[INFO] Starting zeroconf server to advertise on local network.

and from other terminal

root@DietPi7:~/spotifyd# ss -tulpn
Netid   State    Recv-Q   Send-Q      Local Address:Port        Peer Address:Port   Process
udp     UNCONN   0        0                 0.0.0.0:5353             0.0.0.0:*       users:(("spotifyd",pid=11974,fd=10))
udp     UNCONN   0        0                       *:5353                   *:*       users:(("spotifyd",pid=11974,fd=11))
tcp     LISTEN   0        1000              0.0.0.0:22               0.0.0.0:*       users:(("dropbear",pid=1475,fd=3))
tcp     LISTEN   0        1000                 [::]:22                  [::]:*       users:(("dropbear",pid=1475,fd=4))
tcp     LISTEN   0        128                     *:39073                  *:*       users:(("spotifyd",pid=11974,fd=9))

First attempt on the RPi3 failed due to lack of RAM, so I cross-compiled it on WSL2 on my desktop machine.

You can download it here.
If you don’t trust it I can share the steps and you can compile it yourself.

Brilliant, thank you.

One (very) dumb question - where does the compiled library need to go?

Somehow this is know. At least I found similar on spotifyd GitHub. A workaround might be - update librespot to current git version by eladyn · Pull Request #1374 · Spotifyd/spotifyd · GitHub

Seems to be easier compare to do cross compiling :wink:

Thanks, yes in my investigation as to what to do with the file that Jappe provided I realised I could do that so installed the bullseye version of the package and I’m all up and running now.

Thanks!

1 Like

This is a compiled binary, just replace the old one. I guess it’s in /opt/spotifyd/

Can you share what you’ve installed?
In the linked github issue they install

sudo dpkg -i libssl1.1_1.1.1f-1ubuntu2_arm64.deb
sudo dpkg -i libssl-dev_1.1.1f-1ubuntu2_arm64.deb
sudo dpkg -i openssl_1.1.1f-1ubuntu2_arm64.deb

but I think this will not work on an armhf system?

edit:

ah okay they have also armhf version of the package
http://ports.ubuntu.com/pool/main/o/openssl/openssl_1.1.1f-1ubuntu2_armhf.deb

I went with this one to keep things debian: Debian -- Package Download Selection -- libssl1.1_1.1.1w-0+deb11u4_armhf.deb

1 Like

We will have a closer look what happened to spotifyd. Maybe they introduced an issue to the latest version. However its outside our responsibility. We might be able to assist, but its up to spotifyd developers to fix.

Not sure at which point the regression happened. We tested it successfully on all architecture+distro combinations before switching our stable images from Bookworm to Trixie this summer. Issue is that the cross-compiling tool they use pulls very outdated Docker images with Ubuntu 20.04 to build the binaries. Their own CI/CD uses Ubuntu 22.04 runners, hence for x86_64 the issue does not exist.

This will solve it for aarch64, and speed up their CI/CD: ci: build aarch64 natively by MichaIng · Pull Request #1387 · Spotifyd/spotifyd · GitHub

For armv7l it is not so easy, since this requires a armhf toolchain even that the GitHub ARM(v8) runners can execute armv7l binaries. As mentioned in the PR, there is a PR open at that cross-compiling tool to update their Docker images to Ubuntu 24.04. It is however over 1 year old, so I wouldn’t put too much hope in this being merged soon.

Installing EOL libssl1.1 is a worst case workaround, but nothing I’ll promote to the masses, for security reasons alone.

Let’s see the reaction to my PR which solves it at least for the majority of our (and their) users.