Add libwayland-client.so.0 to exclude list

[Zaraka]

I have noticed that my Qt6 AppImage is failing on new distros such as Fedora 40, Arch etc. It turns out an EGL/GLX integration is running into some issues, upon further inspection I found out about this issue here https://gitlab.freedesktop.org/mesa/mesa/-/issues/11316 After removing libwayland-client.so.0 from AppImage all issues were suddenly resolved

[probonopd]

But what if the AppImage is run on a system that does not come with libwayland-client.so.0?

[gartnera]

I hit this today trying to run the Qt6 audacity AppImage today on Arch Linux with sway. It looks like several Qt6 projects already manually exclude this library:

• https://github.com/musescore/MuseScore/pull/24128
• https://github.com/RPCS3/rpcs3/pull/13789

New mesa libgl will call wl_display_create_queue_with_name which is not available in libwayland-client before https://gitlab.freedesktop.org/wayland/wayland/-/commit/b42218f790033c496c48c7d5ba1f8421db794d0b. So long as you exclude libgl I think you have to exclude this library too.

But what if the AppImage is run on a system that does not come with libwayland-client.so.0?

I wasn't able to find any supported distro version that didn't ship this library by default:

@probonopd

[probonopd]

Thanks for your investigation @gartnera. Appreciate it.

The whole Wayland thing has been driving me away from Linux big time.

If we exclude this library, then we can't run those AppImages on systems that are intentionally Wayland-free anymore. I understand that the situation is not ideal, but forcing everyone onto the Wayland bandwaggon isn't, either. Especially those of use who want to stay Wayland-free should imho not be forced to install a Wayland library on the system. (But I guess that's already the fact... Wayland is getting shoved down our throat if we want it or not.)

[gartnera]

systems that are intentionally Wayland-free

At least for QT apps, libwayland-client.so.0 will only be dlopen()'d if the wayland platform is needed and loaded. The top level binary does not link it directly:

I suspect it works like this on most other UI toolkits. SDL seems to have similar options.

But I still don't think this even matters because mesa libegl is going to force you to install libwayland-client0 anyway:

root@0730a7d9f1a4:/# apt install libegl-mesa0
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libbsd0 libdrm-common libdrm2 libexpat1 libgbm1 libwayland-client0 libwayland-server0 libx11-6 libx11-data libx11-xcb1 libxau6 libxcb-dri2-0 libxcb-dri3-0 libxcb-present0 libxcb-randr0 libxcb-sync1 libxcb-xfixes0 libxcb1
  libxdmcp6 libxshmfence1
The following NEW packages will be installed:
  libbsd0 libdrm-common libdrm2 libegl-mesa0 libexpat1 libgbm1 libwayland-client0 libwayland-server0 libx11-6 libx11-data libx11-xcb1 libxau6 libxcb-dri2-0 libxcb-dri3-0 libxcb-present0 libxcb-randr0 libxcb-sync1 libxcb-xfixes0
  libxcb1 libxdmcp6 libxshmfence1
0 upgraded, 21 newly installed, 0 to remove and 3 not upgraded.
Need to get 1296 kB of archives.
After this operation, 4809 kB of additional disk space will be used.
Do you want to continue? [Y/n]

[gartnera]

Also I'm beginning to understand more about how musescore works around this. First, they only use linuxdeploy (and linuxdeploy-qt) to build the initial appdir. Then they have some custom (?) logic which allows "fallback" libraries:

• https://github.com/musescore/MuseScore/blob/master/buildscripts/ci/linux/tools/make_appimage.sh#L243
• https://github.com/musescore/MuseScore/blob/master/buildscripts/packaging/Linux%2BBSD/portable/AppRun.in

[probonopd]

Well then. Let's see where this leads us. Thanks everyone!

[TheAssassin]

I released a new version of linuxdeploy based on this change.

[TheOneRing]

I released a new version of linuxdeploy based on this change.

Thanks, that should also resolve the issue we experienced with KDE Craft on Debian testing.

[Samueru-sama]

Also I'm beginning to understand more about how musescore works around this. First, they only use linuxdeploy (and linuxdeploy-qt) to build the initial appdir. Then they have some custom (?) logic which allows "fallback" libraries:

* https://github.com/musescore/MuseScore/blob/master/buildscripts/ci/linux/tools/make_appimage.sh#L243

* https://github.com/musescore/MuseScore/blob/master/buildscripts/packaging/Linux%2BBSD/portable/AppRun.in

I recommend that you deploy all the libraries with the dynamic linker instead, you avoid all of these issues plus it actually works on any linux system, see examples here.