Issues with Fedora 30 after integrating an AppImage

[lholden]

Hi there!

I've installed AppImage via the RPM package on Fedora 30. The AppImageLauncher application itself seems to run fine. Run Once on an AppImage seems to also work fine. But after having Launcher integrate the AppImage the application will no longer load.

Running the AppImage manually seems to indicate libappimageupdate.so is having issues with libcurl.so.4

AppImageLauncher package: appimagelauncher-2.0.2-travis878.4986e77.x86_64.rpm

$ ./Tiled-1.2.5-x86_64_17cc64a024c8b224db644441d3fa8b89.AppImage 
/usr/bin/AppImageLauncher: /lib64/libcurl.so.4: no version information available (required by /usr/bin/../lib/x86_64-linux-gnu/appimagelauncher/libappimageupdate.so)
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
/usr/bin/AppImageLauncher: symbol lookup error: /usr/bin/AppImageLauncher: undefined symbol: _Z7qt_hashRK7QString

[TheAssassin]

Related to #218.

[TheAssassin]

That libcurl message seems like a warning that shouldn't prevent the app from running.

The error itself, undefined symbol, seems to be related to Qt, it seems to have to do something with the qt_hash() specialization for the QString class.

[skipperTux]

I can confirm the above issue and behavior using the same RPM package version 2.0.2 in Fedora 30 with the following error message:

$ ~/Applications/Station-1.56.0-x86_64_f529222c87d60f2d9d4431f46997564f.AppImage 
/usr/bin/AppImageLauncher: /lib64/libcurl.so.4: no version information available (required by /usr/bin/../lib/x86_64-linux-gnu/appimagelauncher/libappimageupdate.so)
/usr/bin/AppImageLauncher: symbol lookup error: /usr/bin/AppImageLauncher: undefined symbol: _Z7qt_hashRK7QString

The above issue disappears when uninstalling version 2.0.2 and going back to version 1.5.0. In version 1.5.0 AppImage programs can be started without that issue.
The crash when pressing the "choose location" button in AppImageLauncherSettings (#218) does happen in all versions - 1.5.0, 2.0.0, 2.0.1 and 2.0.2.

[valmar]

Can confirm that this happen also with Fedora 31, RC 1.9 which will become Fedora 31 next week

[TheAssassin]

The linking issues are most likely related to libappimage, which nowadays links to libz, which isn't liked by Qt. I don't know why, though, but this is the only major difference you can spot in a direct comparison of what the old and new (0.1.x and 1.0.x) libappimage versions link to.

There is a chance we're simply going to build binaries for Fedora on Fedora for now to provide a short-term fix. But there must be some proper way to get rid of this annoying bug.

[zilti]

Can confirm that this also happens on OpenSUSE Tumbleweed.

[TheAssassin]

@lholden I can't really understand why the dialog works in the one scenario ("run once", first integration) but doesn't in another (running after integration). That kind of indicates that the bug is unrelated to libappimageupdate, right? I mean AppImageLauncher is linked to it, and AppImageLauncher runs in some scenarios. Am I missing something here?

[TheAssassin]

Possibly related: https://forums.gentoo.org/viewtopic-t-1092002-start-0.html

Doesn't provide a solution, though.

[lholden]

I'm guessing that AppImageLauncher as is, works without issue. Run once doesn't modify the appimage, so it will be able to launch the application without issue.

AppImageLauncher then embeds libappimageupdate into the target image, so perhaps in this case, it is the environment of the appimage that is incompatible? I'd think that maybe if libappimageupdate was statically linked to its own dependencies might make it more immune to such issues?.

I'll give it a try with a few other appimages. To be honest, Tiled is the only application I've tried. (If it helps, it can be found here: https://www.mapeditor.org/ )

[TheAssassin]

After having fiddled with this issue and having thought a bit about the actual error message, I found a pretty big problem within my implementation, see aa7b05f. Builds are on the way. The change should solve this particular problem.

[TheAssassin]

Yup, the bionic package e.g., seems to run fine on eoan again, etc. @lholden I'll try Fedora in a few, feedback from you is appreciated as well.

[TheAssassin]

Everything seems to work as intended again. @lholden @valmar @zilti @skipperTux can you please check whether things work again? I'd like to close this issue, make a new release and remove the distro specific package builds again.

[skipperTux]

Fedora 30 Travis build appimagelauncher-2.0.2-travis884.aa7b05f.x86_64.rpm the issue is gone, I can start my AppImage multiple times after integration.

The crash when pressing the "choose location" button in AppImageLauncherSettings (#218) is still there with the following error message:

$ AppImageLauncherSettings 
AppImageLauncherSettings: /lib64/libcurl.so.4: no version information available (required by /usr/bin/../lib/x86_64-linux-gnu/appimagelauncher/libappimageupdate.so)

(AppImageLauncherSettings:26946): Gtk-WARNING **: 22:54:08.938: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/Adwaita/16x16/status/image-missing.png: Fatal error reading PNG image file: bad parameters to zlib (gdk-pixbuf-error-quark, 0)
Aborted (core dumped)

[TheAssassin]

@skipperTux that's a Qt bug that we, unfortunately, cannot solve easily. The only way to fix it would be to use a theme that we also ship with the binaries. I know it's annoying. The problem is tracked in #218.

The general issue seems to be resolved after all.

[lholden]

I think you assassinated the problem @TheAssassin ! Looks like things are good now. :)