Add libgmodule-2.0 to exclude list

[knarfS]

This will fix an error when an AppImage was created with glib < 2.70 and executed with glib >= 2.70:

symbol lookup error: /lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined symbol: g_module_open_full

Full analysis: project-slippi/Ishiiruka#323
Also fixes knarfS/smuview#40

@probonopd I guess updating this file will fix the download in the generate-excludelist.sh scripts of linuxdeploy and liunxdeployqt?

[probonopd]

The interesting question is whether this will in turn cause other breakages.
In some cases, libraries are so closely related that either all or none of a certain set need to be bundled.
I would not be surprised if all of gio should be treated as such a set.

My gut feeling is that we need to bundle all libraries in
https://packages.debian.org/bullseye/amd64/libglib2.0-0/filelist
or none.

libgio-2.0.so.0
libglib-2.0.so.0
libgmodule-2.0.so.0
libgobject-2.0.so.0
libgthread-2.0.so.0

So far, we have been considering glib as something that is provided by the distribution.
Meaning that you should not create AppImages on systems with a newer glib than the target system(s).
E.g., if you produce the ingredients for an AppImage on the oldest still-supported Ubuntu LTS, then it should hopefully run on all still-supported Ubuntu versions.

[knarfS]

The interesting question is whether this will in turn cause other breakages.

Fingers crossed :D

In some cases, libraries are so closely related that either all or none of a certain set need to be bundled. I would not be surprised if all of gio should be treated as such a set.

My gut feeling is that we need to bundle all libraries in https://packages.debian.org/bullseye/amd64/libglib2.0-0/filelist or none.

Yes you are absolutely right. All libs that come with libglib2.0 should be handled the same, either remove all of them or bundle all into the AppImage.
That's exactly what's causing the issue right now: Some of the libglib2.0 libraries are excluded (libgio-2.0.so.0, libglib-2.0.so.0, libgobject-2.0.so.0) and others not (libgmodule-2.0.so.0and libgthread-2.0.so.0). This leads to problems, when the system glib2.0 >= 2.70 and AppImages' glib2.0 < 2.70 are mixed.

I'm not sure what the better solution would be. Maybe bundle all of the glib2.0 libraries?
But on the other hand, not sure what dangerous means in this context, but it somewhat suggests to exclude the libs:
https://github.com/AppImage/pkg2appimage/blob/dd87a9ee27908f5527d1b03c42d4a55c421ebd7e/excludelist#L161-L162

[probonopd]

Addressed with 1e3ecde

[AlexTMjugador]

I'm the developer of an application that links to GStreamer and I want to target Debian Bullseye. To make the AppImage I'm using linuxdeploy and the GStreamer plugin, to bundle all the needed files. I'm building the AppImage on a Debian Bullseye container, because it's the lowest denominator I want to support, and I find that Ubuntu makes things harder with cross-compilation and has more bloat for my taste.

However, when I test the generated AppImage on a Debian Bullseye chroot, I get this error, due to the gobject library not being part of the base, non-GUI distro:

/tmp/.mount_PackSqYahSyB/AppRun.wrapped: error while loading shared libraries: libgobject-2.0.so.0: cannot open shared object file: No such file or directory

Searching the Internet for that error directed me to the exclude list mentioned in this issue and this issue itself, so that's why I think that it might be relevant to comment here.

For my use case, I find that the "so far, we have been considering glib as something that is provided by the distribution" statement is quite unsatisfactory, as I wouldn't call a base Debian Bullseye installation without GLib components a strange system at all (in fact, some users of my application are reporting that they use Debian Bullseye).

Is it feasible to consider bundling all the GLib components in AppImages that need them, not treating GLib as "distribution-provided", even if there are fairly sensible distribution configurations that do not include GLib? The current behavior basically means that users of my AppImage still need to make sure that the GLib package is installed, which partially defeats one of the objectives of AppImages: not having to install packages at all.

[probonopd]

The current behavior basically means that users of my AppImage still need to make sure that the GLib package is installed, which partially defeats one of the objectives of AppImages: not having to install packages at all.

Well.

The objective of AppImage is that you can run applications on most mainstream desktop Linux distributions without having to manually install additional packages besides what they come with out of the box by default on their Live ISOs.

If you really want to make an AppImage that has no dependencies on any distribution-provided packages, why draw the line at GLib? One could argue that a system without glibc is a perfectly fine system as well, and just bundle all libraries. This is what e.g., go-appimage appimagetool -s deploy and https://github.com/AppImageCrafters/appimage-builder do. The result is that you can even run AppImages made on newer build systems on older user systems.

I get this error, due to the gobject library not being part of the base, non-GUI distro

Then you need to ship Xorg as well I guess... which is out of the scope for AppImage, even though technically you might even be able to put it into an AppImage as well.

[AlexTMjugador]

I'm using GStreamer to process audio files in a CLI app, which does not not need a full-blown desktop environment at all. I understand that drawing the line on GLib is somewhat arbitrary, and that if the goal for AppImage is to target desktop environments, then it makes sense to assume it's there. I just wish I had found that out earlier. I'll look into the alternatives you've suggested. Thank you!

[probonopd]

I understand. Yes, for your use case it may be sensible to draw the line there.