Bundle libayatana-appindicator3 in the AppImage so the tray icon works out of the box - #135
Merged
Merged
Conversation
fablevi tested the merged AppImage and hit: Could not open library: libayatana-appindicator3.so.1: cannot open shared object file: No such file or directory Root cause: unlike GTK4/libadwaita (assumed present on any desktop, too big to bundle), libayatana-appindicator3 and its handful of dependencies aren't guaranteed to be installed even on systems that otherwise support tray icons - Fedora doesn't ship it by default. It's small enough to just bundle instead. build-appimage.ts now downloads libayatana-appindicator3-1, libayatana-indicator3-7, libayatana-ido3-0.4-0, libdbusmenu-glib4 and libdbusmenu-gtk3-4 (the full, verified-closed dependency chain - nothing else came back missing from ldd) via `apt-get download` for the target arch, and AppRun sets LD_LIBRARY_PATH so the bare-filename dlopen in @sigmasd/gtk's findLib() picks them up first. aarch64 packages are on Ubuntu's ports archive, not the default one, so that's registered only when cross-building for aarch64. One sharp edge caught in testing: dax's own `cp -r` builtin silently drops symlinks when copying a directory (confirmed empirically), which would have quietly broken every one of these libraries' SONAME symlinks (e.g. libayatana-appindicator3.so.1 -> ...so.1.0.0, the exact name dlopen() is asked for). Used the real /bin/cp for that one copy instead. Verified end-to-end for x86_64: extracted the built AppImage and ran indicator_app.ts through its bundled deno with LD_LIBRARY_PATH set - before this it failed with the reported dlopen error, after it gets all the way past library loading to Gtk.init() (only fails on "cannot open display", expected in this headless sandbox). aarch64 verified as far as this environment allows: confirmed the .deb packages exist on the ports archive and contain genuine aarch64 .so files, and that the full build produces a genuine aarch64 AppImage. Also briefly notes in the README that this - working AppIndicator/tray support - is the AppImage's advantage over the plain stimulator-linux-* binaries, which can't spawn the indicator subprocess at all (see the top-of-file comment on why).
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
2 participants
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.
Summary
I tested the merged AppImage (#134) and hit:
Root cause: unlike GTK4/libadwaita (assumed present on any desktop, too big to bundle),
libayatana-appindicator3and its handful of dependencies aren't guaranteed to be installed even on desktops that otherwise support tray icons - Fedora doesn't ship it by default. It's small enough to just bundle instead.Key Changes
scripts/build-appimage.ts: downloadslibayatana-appindicator3-1,libayatana-indicator3-7,libayatana-ido3-0.4-0,libdbusmenu-glib4andlibdbusmenu-gtk3-4(the full, verified-closed dependency chain vialdd- nothing else came back missing) viaapt-get downloadfor the target arch, andAppRunsetsLD_LIBRARY_PATHso the bare-filenamedlopenin@sigmasd/gtk'sfindLib()picks them up first. aarch64 packages live on Ubuntu's ports archive, not the default one, so that's registered only when cross-building for aarch64.cp -rbuiltin silently drops symlinks when copying a directory (confirmed empirically), which would have quietly broken every one of these libraries' SONAME symlinks (e.g.libayatana-appindicator3.so.1 -> ...so.1.0.0, the exact namedlopen()is asked for). Used the real/bin/cpfor that one copy instead.stimulator-linux-*binaries, which can't spawn the indicator subprocess at all.Testing
Verified end-to-end for x86_64: extracted the built AppImage and ran
indicator_app.tsthrough its bundled deno withLD_LIBRARY_PATHset - before this change it failed with the exact reported dlopen error, after it gets all the way past library loading toGtk.init()(only fails on "cannot open display", expected in a headless sandbox with no display server). aarch64 verified as far as a non-aarch64 environment allows: confirmed the.debpackages exist on the ports archive and contain genuine aarch64.sofiles, and that the full build produces a genuine aarch64 AppImage.🤖 Generated with Claude Code
Generated by Claude Code