MuseScore 4.1.0 / 4.4.0 AppImage does not launch on Debian/bookworm under Wayland

[jlaine]

Issue type

Crash or freeze

Bug description

Running the MuseScore-4.1.0.231921359-x86_64.AppImage binary on Debian bookworm under wayland crashes immediately. The MuseScore-4.0.2.230651545-x86_64.AppImage binary worked fine.

Steps to reproduce

Download the official AppImage and try to run it.

Screenshots/Screen recordings

No response

MuseScore Version

4.1.0

Regression

Yes, this used to work in a previous version of MuseScore 4.x

Operating system

Debian bookworm

Additional context

15:25:47.957 | INFO | main_thread | GlobalModule | onPreInit: log path: /home/XXX/.local/share/MuseScore/MuseScore4/logs/MuseScore_230714_152547.log
15:25:47.957 | INFO | main_thread | GlobalModule | onPreInit: === Started MuseScore 4.1.0, build number 231921359 ===
15:25:47.970 | WARN | main_thread | IpcSocket | connect: failed connect to server
15:25:47.970 | WARN | main_thread | IpcSocket | connect: failed connect to server
15:25:47.970 | INFO | main_thread | IpcSocket | connect: success connected to ipc server
15:25:47.970 | INFO | 139927813613248 | IpcServer | listen: id: "8e2dc1e2f2a7458598fbc6a95fce9f10"
/tmp/.mount_MuseScRs0jDw/bin/mscore4portable: symbol lookup error: /lib/x86_64-linux-gnu/libEGL_mesa.so.0: undefined symbol: wl_proxy_marshal_flags

[jlaine]

This looks similar to https://bugreports.qt.io/browse/QTBUG-114635

AFAICT the AppImage uses a mix of vendored libraries and libraries from the host system, with a version mismatch between libraries. I am still chasing down the exact chain, but I can get MuseScore to run if I do one of the following:

• move plugins/platforms/libqwayland-generic.so out of the way (it's probably falling back to X11 emulation)
• use LD_PRELOAD=/lib/x86_64-linux-gnu/libwayland-client.so.0

The reason the previous release "worked" seems to be that it did not ship with the wayland platform plugin, so it immediately fell back to X11 - not ideal.

[jlaine]

@shoogle looks like this is the PR that changed the behaviour: #13781

Also relevant, linuxdeployqt seems to consider wayland "not supported": probonopd/linuxdeployqt#564

[shoogle]

The reason the previous release "worked" seems to be that it did not ship with the wayland platform plugin, so it immediately fell back to X11 - not ideal.

Correct. As I said in PR #13781, X11 is more reliable than Wayland so Qt will use X11 by default unless you opt-in by setting QT_QPA_PLATFORM=wayland.

If your distribution sets QT_QPA_PLATFORM=wayland by default then you might want to try running unset QT_QPA_PLATFORM before you run MuseScore.

Let us know if that solves it for you and then we can decide whether to always use X11 until Wayland support has improved.

[jlaine]

If your distribution sets QT_QPA_PLATFORM=wayland by default then you might want to try running unset QT_QPA_PLATFORM before you run MuseScore.

Neither my distribution nor my desktop environment (KDE) set the QT_QPA_PLATFORM environment variable.

AFAICT Qt detects it is running under wayland due to the XDG_SESSION_TYPE variable being (correctly) set to wayland.

So, to fall back to X11 I now need to either clear XDG_SESSION_TYPE or explicitly set QT_QPA_PLATFORM=xcb.

Let us know if that solves it for you and then we can decide whether to always use X11 until Wayland support has improved.

Just to be clear, this is not a question of reliability or "support improving", this is a packaging error: the combination of libraries shipped with the binary is bound to fail, because you end up using an incompatible mix of system and vendored libraries!

[MJC-code]

I can confirm this bug also occurs under Debian Unstable, running the KDE desktop with Wayland. The QT_QPA_PLATFORM environment variable is not set.

It does look as if the linuxdeployqt maintainer has no desire to support Wayland, which is a shame for KDE users, since Wayland looks to be the focus of most of the ongoing developer effort in KDE.

[theofficialgman]

This looks similar to https://bugreports.qt.io/browse/QTBUG-114635

I went through those comments and indeed this issue is likely caused by a change wayland side in 1.20+. SDL2 worked around this it seems by adding the symbols to their own binary: libsdl-org/SDL#5092
Ubuntu focal (which is what the appimage is built on) has wayland 1.18 . Not sure if that would fix the runtime error we are seeing or only their build time error.

[theofficialgman]

As expected, modifying the CI to use jammy (22.04) to build the appimage on (wayland 1.20) does produce a functional native wayland build compatible with my system (ubuntu mantic 23.10 on KDE plasma wayland)

https://github.com/theofficialgman/MuseScore/actions/runs/7136789032
theofficialgman@fd9585c

I don't think that is a very suitable solution for MuseScore though as that would make the build incompatible with many older distros (ubuntu focal, debian bullseye, etc)

[cbjeukendrup]

@shoogle See #20391, which basically reverts #13781 for 4.2 because apparently it causes too significant other problems.

[shoogle]

modifying the CI to use jammy (22.04) [...] does produce a functional native wayland build

We can consider doing that around July 2024, after Ubuntu 24.04 LTS has been released and had a few months to stabilize. It's possible that GitHub will begin deprecating the 20.04 image around that time anyway, like they did for 18.04 (although hopefully with more warning and fewer brownouts this time).

Note that we would build against 22.04 not 24.04, but it's worth waiting for the next LTS anyway so that 20.04 users have the option to skip 22.04 and go straight to 24.04.

[RomanPudashkin]

Closing, should be fixed by #20391 (in 4.2.0). Please reopen if you can still reproduce it

[cbjeukendrup]

@RomanPudashkin The fix for this issue was not included in master (4.3), because we want to look for a better fix. The 4.2 fix namely reverts #13781, so brings back the problem that was fixed by that PR. For 4.3, hopefully a way can be found to fix all problems.
So therefore I will reopen this.