From 0d2cc65f17375cfa20e28ab84f1b96b8901d33d5 Mon Sep 17 00:00:00 2001 From: enricobuehler Date: Tue, 28 Jul 2026 17:00:58 +0200 Subject: [PATCH] =?UTF-8?q?fix(gamescope):=20force=20the=20VENDORED=20wlro?= =?UTF-8?q?ots=20=E2=80=94=20the=20binary's=20portability=20was=20luck?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Built the patches on a second distro (Nobara 44 / Fedora 44, for the NVIDIA leg) and the resulting binary would not start on its own host: libwlroots-0.19.so: cannot open shared object file gamescope vendors wlroots as a submodule, but meson prefers a SYSTEM one when the build host has `wlroots-devel` — and links it shared. Fedora 43 has no such package, so the `.116` build fell back to the submodule and linked it statically; Fedora 44's `dnf builddep gamescope` pulls one in, so the same script produced a binary bound to a library that exists only inside the build container. Confirmed rather than assumed: `ldd` on the f43 binary lists no wlroots at all and its log says `Subproject wlroots finished`, while the f44 log says `Dependency wlroots-0.19 found` from the system. The consequence, had Fedora 43 ever shipped `wlroots-devel`: the sysext payload would have carried a gamescope that cannot start, and it would have surfaced to users as "HDR just doesn't work" rather than as a build failure. `-Dforce_ fallback_for=libliftoff,vkroots,wlroots` makes every distro produce the same self-contained binary. All three entries go together — gamescope's own meson.build hard-errors if the first two are dropped from that list. Verified after the fix: `ldd` shows no wlroots/liftoff/vkroots and no missing deps, the binary starts on the Nobara host, and its node offers the same four formats with the colorimetry props — same result as Bazzite f43. --- packaging/gamescope/build-punktfunk-gamescope.sh | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/packaging/gamescope/build-punktfunk-gamescope.sh b/packaging/gamescope/build-punktfunk-gamescope.sh index 62e98b4d..85f65c15 100755 --- a/packaging/gamescope/build-punktfunk-gamescope.sh +++ b/packaging/gamescope/build-punktfunk-gamescope.sh @@ -85,9 +85,20 @@ echo "==> configuring" # package already installs; ours must not collide with it. # (The layer the nested games load is that one — it is version- # independent of the compositor binary.) +# +# `force_fallback_for` includes **wlroots** on purpose, and it is load-bearing for a binary we +# SHIP: gamescope vendors a wlroots submodule, but meson prefers a system one when the build host +# happens to have `wlroots-devel` — and then links it SHARED. The result starts fine on the build +# host and dies with `libwlroots-0.19.so: cannot open shared object file` anywhere else, which is +# every machine that installs our package. Fedora 43 has no wlroots-devel so it fell back and +# linked static by luck; Fedora 44's `dnf builddep gamescope` pulls one in, and the binary built +# there would not start on the host. Pinning the fallback makes the outcome the same everywhere. +# (gamescope's own meson.build hard-errors if libliftoff/vkroots are missing from this list, so +# all three go together.) meson setup "$BUILD" "$SRCDIR" \ --prefix="$PREFIX" \ --buildtype=release \ + -Dforce_fallback_for=libliftoff,vkroots,wlroots \ -Dpipewire=enabled \ -Denable_tests=false \ -Denable_openvr_support=false \