AppImageKit
AppImageKit copied to clipboard
AppImage
/usr/lib/libgio-2.0.so.0: undefined symbol: g_module_open_full
Hi,
First of all, thank you for the great work you are doing!
I've been using the AppImage format for my app (https://github.com/federico-terzi/espanso) for a while, and it seems that since September, the AppImage won't run on an increasing number of distros. When launching the AppImage, we get this error:
/home/lucio/opt/Espanso.AppImage: symbol lookup error: /usr/lib/libgio-2.0.so.0: undefined symbol: g_module_open_full
Searching online, it seems to be happening with multiple app images:
- https://github.com/VSCodium/vscodium/issues/919
- https://forum.manjaro.org/t/vscodium-appimage-wont-launch-symbol-lookup-error-libgio/84462/3
- https://bbs.archlinux.org/viewtopic.php?id=269838
- https://github.com/FastTrackOrg/FastTrack/issues/25
From a first analysis, it seems that the library has been explicitly excluded from the AppImage: https://github.com/AppImage/pkg2appimage/blob/master/excludelist#L86
Do you have any tips/guidance on the best way to approach this problem?
Thanks!
Just noticed this might be related: https://github.com/AppImage/pkg2appimage/issues/494
Which distribution and version are you building the ingredients that go into your AppImage on? It's probably too new.
Looks like this issue is similar to https://github.com/srevinsaju/guiscrcpy/issues/268#issue-1044574005, I was wondering on the root cause. The appimage was built on ubuntu18.04,
@probonopd Thanks for the reply!
Which distribution and version are you building the ingredients that go into your AppImage on?
I'm building the app image inside a Docker container with Ubuntu 18.04, these are the relevant steps:
FROM ubuntu:18.04
RUN apt-get update \
&& apt-get install -y libssl-dev \
libxdo-dev libxtst-dev libx11-dev \
libxkbcommon-dev libwxgtk3.0-gtk3-dev libdbus-1-dev \
wget git file build-essential pkg-config
https://github.com/project-slippi/Ishiiruka/issues/323 contains an analysis of what is causing the issue and a workaround. Please let me know whether the workaround works for you, then we should probably add libgmodule-2.0.so to the excludelist.
@probonopd Thanks! can confirm that the workaround specified there works on Fedora 35 Silverblue.
Just to chime in here, the proposed workaround (removing libgmodule-2.0.so.0 from an unsquashed appimage) helped AppImageLauncher to function on a Fedora 35 machine (see https://github.com/TheAssassin/AppImageLauncher/issues/472).
Someone has to test whether the proposed exclusion will break older systems. If not, it should be implemented ASAP.
Can confirm the workaround works on both up-to-date Manjaro and Fedora 35, not sure about older systems
I have tested the workaround above (removing libgmodule-2.0.so.0 from an unsquashed AppImageLauncher) on an Ubuntu Bionic VM (18.04.6 x86_64). The workaround still allows the app to function and run, same as before the workaround. I believe this confirms the workaround does not break Ubuntu Bionic.
@probonopd since you recently modified the excludelist, I assume this issue can be closed, right?
@TheAssassin @probonopd I've just tried with the latest linuxdeploy AppImage release:
linuxdeploy version 1-alpha (git commit ID ed42a40), GitHub actions build 75 built on 2022-03-15 12:03:03 UTC
Unfortunately, it doesn't solve the problem... In fact, even the workaround seems to have stopped working (removing libgmodule), and now it fails with:
symbol lookup error: /lib64/libgobject-2.0.so.0: undefined symbol: g_uri_ref
Not sure whether the latest linuxdeploy AppImage release already reflects the latest changes in https://github.com/AppImage/pkg2appimage/blob/master/excludelist.
@probonopd Thank you, I really appreciate your hard work! I'll make sure to re-test the build once you feel it's the right time (for now, I've solved the problem vendoring an older version of linuxdeploy and appimagetool inside the repo, about a month old)
@federico-terzi could you please post links to a non-working and a working (using your manual workaround) version. Thanks!
@probonopd Sure thing! Here we go:
- This works (using an older linuxdeploy + appimagetool version, about a month old, + the manual workaround of removing
libgmodule): https://github.com/federico-terzi/espanso/releases/download/v2.1.5-beta/Espanso-X11.AppImage - This doesn't: https://github.com/federico-terzi/espanso/releases/download/v2.1.4-beta/Espanso-X11.AppImage
These are the steps to build the app image: https://github.com/federico-terzi/espanso/blob/master/scripts/create_app_image.sh
Thanks @federico-terzi. As I am a bit overloaded with other work at the moment: Could you extract both AppImages and find out the differences between them in terms of which files are contained? Thanks!
| Files only in working v2.1.5 | Files only in non-working v2.1.4 |
|---|---|
| ... | ... |
| ... | ... |
Still a issue.
https://github.com/PaulCombal/SamRewritten
[k1ll3rpunch@archlinux Загрузки]$ /home/k1ll3rpunch/Загрузки/SamRewritten-Ubuntu_18.04--d29ad13-x86_64.AppImage /tmp/.mount_SamRew2FkY23/usr/bin/samrewritten: symbol lookup error: /usr/lib/libgio-2.0.so.0: undefined symbol: g_module_open_full
Having this issue as well on latest Manjaro:
./timecamp.AppImage: symbol lookup error: /usr/lib/libgio-2.0.so.0: undefined symbol: g_module_open_full
While I haven't had the time to investigate the root cause, https://github.com/rncbc/qtractor/issues/317 seems to suggest that new versions of libgio-2.0 on the target system might be causing this.
This needs systematic experimentation.
If it runs out that a "too new" libgio-2.0 on the target system can cause this, then it might be an ABI break in that library, something that I'd consider a bug if it happens within the same major version of the library. But again, let's not jump to conclusions before this is thoroughly investigated.
Unfortunately,
https://abi-laboratory.pro/index.php?view=navigator&symbol=g_module_open_full#result
doesn't even know this symbol.