search

solemnwarning / rehex

Reverse Engineers' Hex Editor
https://rehex.solemnwarning.net/
GNU General Public License v2.0
2.3k stars 113 forks source link

AppImage doesn't run well on all systems #233

Closed solemnwarning closed 3 months ago

solemnwarning commented 3 months ago

The AppImage binaries are currently being built using linuxdeploy and its default AppImage runtime which depends on FUSE 2.

From a brief test, using the runtime from here with linuxdeploy at least starts on Ubuntu 22.04, but all the icons are broken. I've spent a while poking at it and for whatever reason, GTK 2 is just failing to load the icons from the system claiming it can't recognise the format (it works fine on my Debian 12 machine).

So the path here is (probably) to use the newer (statically-linked) AppImage runtime, possibly add fallback icons for whenever the system defaults cannot be loaded (maybe only for AppImage builds), and test the result on a jillion different distros. Wheee.

solemnwarning commented 3 months ago

Its fixed now, the short answer is the AppImage needed to be built with the linuxdeploy-plugin-gtk plugin, the long answer with relevant error messages is below for the benefit of anyone else trying to solve this problem in the future.

When running the REHex AppImage on Ubuntu 24.04, none of the "stock" icons were loaded, and the console was full of errors like the following:

(rehex-0.61.1-linux-generic-x86_64.AppImage:7550): Gtk-WARNING **: 14:28:17.235: Error loading theme icon 'document-new' for stock: Unrecognized image file format

I found a lot of bugs and threads about similar-looking but unrelated issues, most of them stating the system's MIME database or the gdk pixbuf loader cache was out of date and needed rebuilding - doing so didn't help.

As an experiment, I rebuilt the AppImage using the GTK3 version of wxWidgets from Ubuntu 20.04, and that made the problem worse - not only did it fail to load icons, but that went from making the UI a mess to making it crash at startup, because the icon failing to load caused an assertion failure inside GTK, after all, why wouldn't it.

GTK uses GdkPixbuf internally to load image files, and GdkPixbuf supports external image loading libraries (e.g. loaded from /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/<version>/loaders/*.so). Older versions of Ubuntu shipped with the png loader as an external library, however at some point the build configuration was changed and the png loader was embedded directly into the core GdkPixBuf library, meaning there was no longer a separate libpixbufloader-png.so for the bundled GTK libraries to load.

The detailed solution here is that the libpixbufloader-xxx.so libraries from the build host needed to be embedded in the AppImage, and some environment variables set within AppRun to make GTK load them rather than trying to find them on the target. The linuxdeploy-plugin-gtk plugin referenced above does this, and probably other things I didn't know should be done.