fix(desktop): strip over-bundled libraries from the AppImage - #309
Merged
Conversation
Addresses #285, and corrects my own diagnosis of it. I had blamed the AppImage wrapper forcing GDK_BACKEND=x11. That forcing is real, but it is not the cause — and it is deliberate, working around a Wayland-backend crash (tauri#8541), so it should stay. The actual mechanism is documented upstream in tauri#15665: linuxdeploy's dependency follower sweeps libwayland-client and the glib/gstreamer family into usr/lib, and its excludelist does not cover them (the pkg2appimage community excludelist does, noting that bundling libwayland breaks newer Mesa). On a host whose Mesa is newer than the build machine's, the system EGL driver is loaded against the BUNDLED libwayland-client, eglGetDisplay() returns EGL_BAD_PARAMETER, and WebKitWebProcess aborts — no window, nothing useful on the terminal. The reporter's own workaround is the same mechanism seen from the other side: LD_PRELOAD of the host libwayland-client displaced the bundled one. That detail was in the first message and I read past it. Verified against our actual artifact in a Fedora 44 container, not inferred: every library tauri#15665 names is present in our AppImage — libwayland-client, libwayland-egl, the glib family, 10 libgst*, libmount/libblkid/libselinux/libpcre2-8, libzstd/libelf/libffi. 29 files in total. (Mechanism 2 from that issue, a stale GST_PLUGIN_SYSTEM_PATH, does NOT apply to us — we export no such variable.) Upstream has no configuration surface for this: `appimage.files` can only add files, not remove or symlink them, so post-processing is the only avenue until an excludeLibraries-style option exists. The issue author reached the same conclusion. Tested end to end on Fedora 44: - strip + repack succeeds; 134 -> 105 libraries in usr/lib - the repacked AppImage extracts and its sidecar serves HTTP 302 - ldd reports 0 missing libraries for rustfava-desktop AND for the bundled libwebkit2gtk-4.1 — the system versions are drop-in, which is what makes removal safe - running the script twice emits its ::warning:: on the second pass, so a future upstream fix (or an AppDir layout change) surfaces as a visible no-op rather than a silent one What I could NOT test is the EGL initialisation itself: that needs a real GPU and compositor, which a headless container has not got. So the mechanism is proven and the removal is proven safe, but the fix awaits confirmation from the reporter's hardware. actionlint: 6 findings before and after, none in the new step.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses #285 — and corrects my own diagnosis of it.
I had blamed the AppImage wrapper forcing
GDK_BACKEND=x11. That forcing is real, but it isn't the cause — and it's deliberate, working around a Wayland-backend crash (tauri#8541), so it stays.The actual mechanism
Documented upstream in tauri#15665 (open,
platform: Linux): linuxdeploy's dependency follower sweepslibwayland-clientand the glib/gstreamer family intousr/lib, and its excludelist doesn't cover them — the pkg2appimage community excludelist does, noting that bundling libwayland breaks newer Mesa.On a host whose Mesa is newer than the build machine's, the system EGL driver is loaded against the bundled
libwayland-client,eglGetDisplay()returnsEGL_BAD_PARAMETER, and WebKitWebProcess aborts. No window, nothing useful on the terminal.The reporter's own workaround is that mechanism seen from the other side:
LD_PRELOADof the hostlibwayland-clientdisplaced the bundled one. That detail was in their first message and I read past it.Verified against our artifact, not inferred
In a Fedora 44 container, every library tauri#15665 names is present in our AppImage:
libwayland-client,libwayland-egl,libglib-2.0,libgio-2.0,libgobject-2.0,libgmodule-2.0, 10 ×libgst*,libmount,libblkid,libselinux,libpcre2-8,libzstd,libelf,libffi— 29 files.Mechanism 2 from that issue (a stale
GST_PLUGIN_SYSTEM_PATHwhenbundleMediaFramework: false) does not apply to us — we export no such variable. I checked rather than assuming both applied.Why post-processing
Upstream has no config surface:
bundle.linux.appimage.filescan only add files, not remove or symlink. The issue author reached the same conclusion — "we're stuck post-processing the AppImage in CI".Tested end to end on Fedora 44
usr/lib134 → 105ldd rustfava-desktopldd libwebkit2gtk-4.1.so.0::warning::, strips 0The two
lddresults are the ones that make removal safe: the system versions are drop-in, exactly as upstream reported. The warning path means a future upstream fix — or an AppDir layout change — surfaces as a visible no-op rather than a silent one.What I could not test
The EGL initialisation itself needs a real GPU and compositor, which a headless container hasn't got. So the mechanism is proven and the removal is proven safe, but the end-to-end fix awaits confirmation on the reporter's hardware.
actionlint: 6 findings before and after, none in the new step.