Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug] Linux AppImage: bundled libwayland-client.so.0 breaks EGL on newer Mesa hosts - WebProcess aborts (EGL_BAD_PARAMETER), blank window

Open
#3,226 0 comments 0 reactions 0 assignees View on GitHub

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

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 as Could not create surfaceless EGL display: EGL_BAD_ALLOC. Aborting... — same root area, different vendor path.
  • No WebKitWebProcess is ever alive (it dies at startup); only WebKitNetworkProcess survives, so the page never renders.
  • webview.log stays 0 bytes; app.log shows Startup 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)

  1. Extracted the published v1.0.1 AppImage to a directory (--appimage-extract).
  2. Deleted only squashfs-root/usr/lib/libwayland-client.so.0.
  3. Ran the extracted AppRun with WEBKIT_DISABLE_DMABUF_RENDERER=1 on an X11 session.
  4. Result: WebKitWebProcess stays alive, no EGL abort on stderr, webview.log fills 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from GCWing/OpenBitFun

All issues in GCWing/OpenBitFun

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.