Sunshine does not start anymore after upgrading to Ubuntu 24.10

[RobertBleyl]

Is there an existing issue for this?

• I have searched the existing issues

Is your issue described in the documentation?

• I have read the documentation

Is your issue present in the latest beta/pre-release?

This issue is present in the latest pre-release

Describe the Bug

After upgrading to Ubuntu 24.10 (from 24.04) sunshine does not start anymore. The following error message is printed:
sunshine: error while loading shared libraries: libminiupnpc.so.17: cannot open shared object file: No such file or directory

It does not work with the current release version (0.23.1) nor the current pre-release version (2024.1021.153031)

Expected Behavior

sunshine starts without error on Ubuntu 24.10.

Additional Context

No response

Host Operating System

Linux

Operating System Version

Ubuntu 24.10

Architecture

amd64/x86_64

Sunshine commit or version

2024.1021.153031

Package

Linux - deb

GPU Type

AMD

GPU Model

RX 7600 XT

GPU Driver/Mesa Version

Mesa 24.2.3-1ubuntu1 (LLVM 19.1.0)

Capture Method

None

Config

No response

Apps

No response

Relevant log output

Error: Client failure: Daemon connection failed

[ReenigneArcher]

We don't provide a deb for 24.10, you will have to self compile.

[iso2013]

FWIW, this issue can be fixed bypassed by running sudo ln -s /usr/lib/x86_64-linux-gnu/libminiupnpc.so.18 /usr/lib/x86_64-linux-gnu/libminiupnpc.so.17

Ubuntu 24.10 changes the version of the miniupnpc package that's used and so the file name changes. Note that this is pretty likely to lead to other issues but since I don't use PnP anyway it's not an issue so far for me

[ReenigneArcher]

17 and 18 are not interchangeable, so you are correct that it will only work if you disable the upnp options in Sunshine.

[flotwig]

@ReenigneArcher does the Sunshine project have a policy to not support non-LTS Ubuntu versions? It could be nice to get a build for 24.10 going. I spent a while trying to build it today on 24.10, ultimately failing, before using the symlink @iso2013 suggested. I could try opening a PR if it would be welcome.

[ReenigneArcher]

We do not build for non LTS debian, as it already consumes a ton of resources to build for the 3 we do support (thanks to arm compilation with qemu).

When you self compile you shouldn't need to create any symbolic link.

3 PRs I would like to see on this front, but haven't had time to work on:

1. Static link this, and other, dependencies so we could hopefully distribute just a single deb instead of several.
2. Cross compile in our debian docker builds instead of using qemu to significantly reduce compilation time
3. Fix docker build caching issues to avoid the double compilation that were introduced after moving to our common build script in build(linux): add common build script #2946

[famellad]

Experiencing the same problem right now in Arch, also not using UPnP, also bypassed by just fake linking the new version with the old name.
I have read the old issue here that miniupnpc should not be required, if the user is not going to enable UPnP, what I don't understand is what's stopping the software to simply check for the existance of the library upon starting, and simply greying out the option if it's missing? You wouldn't have to maintain an entirely new UI.
In any case, I get this is very low priority and the workaround is so simple it's barely worth discussing.

[ReenigneArcher]

same problem right now in Arch

You need to rebuild, or just use our pre-built packages from https://github.com/LizardByte/pacman-repo