[Bug] Linux AppImage: bundled libwayland-client.so.0 breaks EGL on newer Mesa hosts - WebProcess aborts (EGL_BAD_PARAMETER), blank window
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 68/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- linux, rust, tauri
- Domain
- build-system, desktop, operating-systems
Research direction
Start by locating the Linux AppImage build configuration and its linuxdeploy packaging rules. Exclude libwayland-client.so.0 and the other host-coupled graphics libraries described in the issue, rebuild and test the extracted AppImage on a newer Mesa host, then verify that WebProcess stays alive, the UI renders, and latest.json remains valid for updates.
Written by the indexing model from the issue text.
Description
Summary
On an Arch-based host (EndeavourOS) running Mesa 26.x + libglvnd, the official linux-x86_64 AppImage (v1.0.1) opens but stays blank/white. WebKit's WebProcess aborts during EGL initialization and never comes back:
Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...
The GTK shell window survives, so the user-visible symptom is a permanent blank window rather than a crash.
This appears to be the same AppImage packaging issue documented for another Tauri + WebKitGTK app here: https://github.com/sftwrdotdev/Markpad/issues/498
Environment
- Host: EndeavourOS (Arch-based), x86_64, VM without usable GPU (VMware 3D acceleration off; software rendering via llvmpipe)
- Mesa 1:26.2.2, libglvnd 1.7.0, system webkit2gtk-4.1 2.52.6
- Session: X11 via xrdp/Xvnc (
DISPLAY=:10) - OpenBitFun v1.0.1 AppImage (
OpenBitFun_1.0.1_linux-x86_64.AppImage)
Symptoms / observed behavior
- stderr right after the banner
=== OpenBitFun Desktop Starting ===:Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...(pure-Mesa environment)- On a system that additionally carries leftover NVIDIA EGL vendor files (
/usr/share/glvnd/egl_vendor.d/10_nvidia.json,libnvidia-*.so), the first failure instead surfaces asCould not create surfaceless EGL display: EGL_BAD_ALLOC. Aborting...— same root area, different vendor path.
- No
WebKitWebProcessis ever alive (it dies at startup); onlyWebKitNetworkProcesssurvives, so the page never renders. webview.logstays 0 bytes;app.logshowsStartup page did not finish loading before the window reveal watchdog.- Reproduced both from the FUSE-mounted AppImage and via
--appimage-extract-and-run. A strace of the dying WebProcess shows it loading/usr/lib/libEGL.so.1(glvnd), then aborting right after vendor probing — before any DRI driver is reached.
Root cause analysis
The AppImage bundles usr/lib/libwayland-client.so.0 (built against the ubuntu-24.04 runner). Because LD_LIBRARY_PATH puts the AppImage directories first, that older copy shadows the host's libwayland-client for every process in the AppImage tree, including WebKit's WebProcess. The host libEGL (libglvnd) links libwayland-client, and with the mismatched older copy in place, eglGetPlatformDisplay is rejected at the EGL dispatch entry with EGL_BAD_PARAMETER before any DRI driver is even loaded (Mesa verbose logging prints nothing useful, consistent with a rejection at dispatch entry).
This matches exactly the single-library isolation result reported in Markpad #498 (same stack: Tauri + WebKitGTK 2.52.x AppImage built on ubuntu-24.04, tested on Arch/Mesa 26): removing only libwayland-client.so.0 from the AppDir is necessary and sufficient — the full UI then renders.
Verification performed (on this host)
- Extracted the published v1.0.1 AppImage to a directory (
--appimage-extract). - Deleted only
squashfs-root/usr/lib/libwayland-client.so.0. - Ran the extracted
AppRunwithWEBKIT_DISABLE_DMABUF_RENDERER=1on an X11 session. - Result:
WebKitWebProcessstays alive, no EGL abort on stderr,webview.logfills up — the frontend completes full startup (Tauri API initialized, Monaco Editor initialized, I18n / config / language registries ready) and no watchdog warning is emitted. UI renders normally.
Note: env workarounds alone (WEBKIT_DISABLE_DMABUF_RENDERER=1, WEBKIT_DISABLE_COMPOSITING_MODE=1, LIBGL_ALWAYS_SOFTWARE=1) do not fix the shipping AppImage — consistent with Markpad #498's findings.
Suggested fix
Exclude host-coupled graphics libraries from the AppImage at build time (linuxdeploy excludelist, per AppImageCommunity/pkg2appimage guidance) — at minimum libwayland-client.so.0, ideally the full set: libwayland-*, plus libEGL/libGL/libgbm/libdrm/libxcb* if present.
Caveat for maintainers: a repacked AppImage must be re-signed and latest.json regenerated, or the auto-updater breaks (same note as in Markpad #498).
Repro caveat
The bug is host-version dependent: it only manifests when the host's Mesa/libwayland are newer than the build runner's. Builds and tests on the ubuntu-24.04 runner (or on hosts matching it) will not catch this; a CI smoke test on a recent Arch/Mesa image would have caught both this and any future recurrence of the same class of packaging problem.
- Dominant language
- Rust
- Stars
- 2.3k
- Forks
- 236
- Avg merge
- 2h 53m
- Merged PRs (30d)
- 604
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from GCWing/OpenBitFun
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
GCWing/OpenBitFun#3213 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
GCWing/OpenBitFun#2363 ·
-
question
Difficulty 1/5 Under an hour Newbie friendliness 78/100
GCWing/OpenBitFun#2340 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 72/100
GCWing/OpenBitFun#3225 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
GCWing/OpenBitFun#3222 ·
All issues in GCWing/OpenBitFun
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
bug good first issue package: quic
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
-
`dora trace view` sends a non-canonical full UUID as-is, so a valid trace ID shows "No spans found" Opencli coordinator rust
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
area: tasks enhancement good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Jason-jo17/Polybench#15 · 1 comment ·