Error starting Sunshine service after "boost-libs" package upgrade (libboost_locale)

[afonsobm]

Is there an existing issue for this?

• [X] I have searched the existing issues

Is your issue described in the documentation?

• [X] I have read the documentation

Is your issue present in the nightly release?

• [X] This issue is present in the nightly release

Describe the Bug

On September 2nd, the Arch Linux repos have updated the package "boost-libs" from 1.81 to 1.83 After this update, the sunshine service is not starting anymore due to not being able to find libboost_locale.so.1.81 (service error in screenshot below)

Downgrading the package back to 1.81 solves the issue.

Expected Behavior

Service should not crash while starting.

Additional Context

My sunshine is built from the AUR, however I've also tried the nightly AppImage build and it has the same issue.

Host Operating System

Linux

Operating System Version

Arch Linux - Kernel 6.4.14

Architecture

64 bit

Sunshine commit or version

0.20.0

Package

Linux - AUR (Third Party)

GPU Type

AMD

GPU Model

Radeon RX 7900XT

GPU Driver/Mesa Version

23.1.6

Capture Method (Linux Only)

KMS

Config

capture = kms
min_threads = 2
encoder = vaapi

Apps

No response

Relevant log output

sunshine: error while loading shared libraries: libboost_locale.so.1.81.0: cannot open shared object file: No such file or directory

[5arer]

Just been hit by this as well :) Tried both AUR from source and bin and they have same problem.

Edit: the workaround is to downgrade to boost and boost-libs 1.81 obviously

[ReenigneArcher]

Neither "sunshine-git" nor "sunshine-bin" are supported here.

I think you need to recompile Sunshine and link to the version of boost you have. I would suggest using the PKGBUILD from our nightly release if you want nightly, otherwise "sunshine" aur package should work.

[afonsobm]

@ReenigneArcher Tried uninstalling and rebuilding the package from the AUR... the service is now working.

I opened this issue because I've tried the AppImage nightly and it gave me the same error so I thought it was an App issue... I might've done something wrong.

Since I can run it on the latest package, I will be closing the issue. Thanks for the help!

[5arer]

Neither "sunshine-git" nor "sunshine-bin" are supported here.

I think you need to recompile Sunshine and link to the version of boost you have. I would suggest using the PKGBUILD from our nightly release if you want nightly, otherwise "sunshine" aur package should work.

Indeed although that PKGBUILD comes with enet included which conflicts with enet package itself.

[poc-sm]

Why you can't fix this in your build and push it with good libs version ? Why enduser need to recompile ? and what's happen with next upgrade ? I am a bit confused I can't downgrade lib-boost ... and I don't want to recompile at each update with good libs version ...

[ReenigneArcher]

From the discussions I've had, most linux developers disagree with static linking, so that is why Sunshine on Linux uses dynamic linking... and this is one of the many problems with using dynamic linking.

[escape0707]

@poc-sm This is just how dynamic linking and binary AUR packages works. The -bin package is just a lazy cheesy way to avoid building packages by directly downloading the upstream binary. But if the dependencies got updated and the ABI breaks, then you will always need an updated binary which is rebuilt against the updated dependencies, no matter who you are.

Well, technically you could still downgrade the dependencies, but downgrading is generally not recommended by ArchLinux, especially if it is boost-libs. In some cases, you could also create a symlink to the latest .so file with the name of the old versions, but I've just tried that, and unfortunately it doesn't work this time.

If the package is got adopted by any Arch Trusted Users and made its way into the official repositories, then you will not have this kind of trouble. You can then just download the rebuilt binary from the official repo. This is how most of the ABI breakage got resolved, but it's only because some TU has done the rebuilt for you.

So, unless the upstream would like to release a rebuilt "sunshine.pkg.tar.zst" somewhere, just build the aur/sunshine package and use that instead.

Or you could find if any third party repos included this package. Although I co-maintain the -bin AUR package for the easy installing on one of my headless servers, I personally use a prebuilt sunshine package from a third party repo I've set up.

[poc-sm]

@poc-sm This is just how dynamic linking and binary AUR packages works. The -bin package is just a lazy cheesy way to avoid building packages by directly downloading the upstream binary. But if the dependencies got updated and the ABI breaks, then you will always need an updated binary which is rebuilt against the updated dependencies, no matter who you are.

Yes I understand

Well, technically you could still downgrade the dependencies, but downgrading is generally not recommended by ArchLinux, especially if it is boost-libs. In some cases, you could also create a symlink to the latest .so file with the name of the old versions, but I've just tried that, and unfortunately it doesn't work this time.

No can't do I've got depencies on my system app with snapper and other things wich result to a nightmare downgrade

If the package is got adopted by any Arch Trusted Users and made its way into the official repositories, then you will not have this kind of trouble. You can then just download the rebuilt binary from the official repo. This is how most of the ABI breakage got resolved, but it's only because some TU has done the rebuilt for you.

Yeah that the point, I was thinking some one here maintain this package on the repo but seems not https://aur.archlinux.org/packages/sunshine
I expected to someone make the fix and the build and share it with aur for other people like me

So, unless the upstream would like to release a rebuilt "sunshine.pkg.tar.zst" somewhere, just build the aur/sunshine package and use that instead.

Yes

Or you could find if any third party repos included this package. Although I co-maintain the -bin AUR package for the easy installing on one of my headless servers, I personally use a prebuilt sunshine package from a third party repo I've set up.

I just will do this if nobody maintain the aur package I'll make a search but if you have sugested repo, I am interested Thanks

[ReenigneArcher]

Yeah that the point, I was thinking some one here maintain this package on the repo but seems not https://aur.archlinux.org/packages/sunshine I expected to someone make the fix and the build and share it with aur for other people like me

@poc-sm The PKGBUILD in sunshine AUR will already work fine, but it depends on the dependencies on your system at build time. Since Boost was updated after you built Sunshine, then it is now linked against a missing library. Re-build/re-install Sunshine and it will work fine.

I personally use a prebuilt sunshine package from a third party repo I've set up

@escape0707 we already have pre-build packages here: https://github.com/LizardByte/Sunshine/releases/nightly-dev (or under any official release)

[poc-sm]

Yeah that the point, I was thinking some one here maintain this package on the repo but seems not https://aur.archlinux.org/packages/sunshine I expected to someone make the fix and the build and share it with aur for other people like me

@poc-sm The PKGBUILD in sunshine AUR will already work fine, but it depends on the dependencies on your system at build time. Since Boost was updated after you built Sunshine, then it is now linked against a missing library. Re-build/re-install Sunshine and it will work fine.

Ho yes you exactly right thanks you so much ... I feel pretty dumb

[escape0707]

Ho yes you exactly right thanks you so much ...

Yeah, it seems that all you need is to force a rebuild against updated dependencies again and everything shall be fine.

I just will do this if nobody maintain the aur package I'll make a search but if you have sugested repo, I am interested Thanks

I'm personally using ArchLinuxCN repo as I'm familiar with those people and sometimes discuss linux techniques and learn from them. But I can understand that you may want to use other repos of your own choice. A good source is https://wiki.archlinux.org/title/unofficial_user_repositories

@escape0707 we already have pre-build packages here: https://github.com/LizardByte/Sunshine/releases/nightly-dev (or under any official release)

The so called sunshine-bin package I co-maintained is sourcing the GitHub release prebuilt binary. The problem is that the latest 0.20 version binary is linked with old boost-libs. So unless there is an official release binary linked to boost-libs 1.83, there is nothing to do on the AUR side. I've not tried the nightly build, but if it's compiled with the latest boost, then it might be useful for some people.

The third party repo I'm using is basically just letting me download the binary they built from aur/sunshine.

[ReenigneArcher]

@escape0707 okay, you could also use the PKGBUILD from releases. Again it's published for both stable and nightly.

I just hate to see all this duplication, and it's somewhat difficult to support. We do build an Arch package in our CI pipeline and verify it builds before any merge request is accepted. Then we publish the PKGBUILD and pre-built package to the nightly release. Same for official releases. The aur/sunshine is co-maintained by me (@LizardByte is our dedicated account)... and by @KuleRucket who has been helping out on the Linux and Arch side since we took over maintenance this repo.

It'd be cool if we could all discuss on our Discord server possible ways to consolidate. As far as I know there are 3 different AUR packages.

We sort of have the same issue with flatpak. The flathub version is not matching our repo version.

[escape0707]

Oh, thank you for the explanation. I do recognize that a "-bin" package is not an elegant way to install non-distro-official packages. The only time that I made use of it is because I want to quickly try sunshine on a shared remote machine with minimal footage. Besides that, I just use aur/sunshine, both built by makepkg and third party repo.

For me, there is no confusion about how things works. But if currently the bin packages users' questions become a burden to the upstream, I'll make sure to leave a pinned comment on the AUR page to avoid it. (Actually I've already left one

As far as I know there are 3 different AUR packages.

This is totally fine. One bin package for users who want to install from upstream binary releases, one package without any suffix for compiling from upstream latest released source code (tar), and one -git package for users who prefer to sync and compiling upstream git repo. I actually think that maybe someone will create another sunshine-nightly-bin package some other day to install the nightly binary, and that is totally fine, too.

Finally, thanks for maintaining this amazing software!