Skip to content

fix(desktop): strip over-bundled libraries from the AppImage - #309

Merged
robcohen merged 1 commit into
mainfrom
fix/appimage-overbundled-libs
Aug 23, 2026
Merged

fix(desktop): strip over-bundled libraries from the AppImage#309
robcohen merged 1 commit into
mainfrom
fix/appimage-overbundled-libs

Conversation

@robcohen

Copy link
Copy Markdown
Member

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 sweeps libwayland-client and the glib/gstreamer family into usr/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() returns EGL_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_PRELOAD of the host libwayland-client displaced 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, libffi29 files.

Mechanism 2 from that issue (a stale GST_PLUGIN_SYSTEM_PATH when bundleMediaFramework: 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.files can 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

check result
strip + repack succeeds, usr/lib 134 → 105
repacked AppImage runs extracts; sidecar serves HTTP 302
ldd rustfava-desktop 0 missing
ldd libwebkit2gtk-4.1.so.0 0 missing
second run on same file emits ::warning::, strips 0

The two ldd results 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.

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.
@robcohen
robcohen merged commit 7814187 into main Aug 23, 2026
33 checks passed
@robcohen
robcohen deleted the fix/appimage-overbundled-libs branch August 23, 2026 11:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant