Nightly won't start on openSUSE Tumbleweed

[tresf]

It appears that by removing our LD_LIBRARY_PATH=usr/lib from our launcher script in #7686 it's causing more issues.

This is a report from a user on Reddit:

  me@localhost:~/Downloads/GameDev/Audio> ./nightly*.AppImage
  [carla-hook.sh] Carla appears to be installed on this system at /usr/lib64/carla so we'll use it.
  ldd: warning: you do not have execution permission for `/usr/lib64/carla/libcarla_native-plugin.so'
  [carla-hook.sh] Preferring the system's "libgobject-2.0.so.0" over the version bundled.
- /tmp/.mount_nightlAdO0bw/apprun-hooks/jack-hook.sh: line 6: ldconfig: command not found
  [jack-hook.sh] Jack does not appear to be installed.  That's OK, we'll use a dummy version instead.
- /tmp/.mount_nightlAdO0bw/AppRun.wrapped: error while loading shared libraries: libdb-5.3.so: cannot open shared object file: No such file or directory`

... I tested the AppImage out on Tumbleweed and I can confirm, Tumbleweed ships with libdb-4.8.so and we expect libdb-5.3.so.

Workarounds:

Outdated, click to expand anyway

1. (NOT RECOMMENDED) Force LMMS to use the system version.

   • This seems to work just fine, but has risks as it modifies the root filesystem and may cause crashes if there are substantial API changes between libdb versions.

   sudo ln -s /usr/lib64/libdb-4.8.so /usr/lib64/libdb-5.3.so

2. (RECOMMENDED) Start LMMS from the extracted "usr/lib" directory. This will place our copy of libdb on the path, but may introduce more VST crashes, as it was our copy of libreadline that caused this mess to begin with.

   ~/Downloads/lmms-1.3.0-alpha.1.755+g6a0a4cd2b-linux-x86_64.AppImage --appimage-extract && pushd squashfs-root/usr/lib && ../../AppRun && popd && rm -rf squashfs-root/

[tresf]

Ok... it appears some things have changed since we bundled libjack. Mainly, libjack is now in the appimage exclude list.

The source comment shows that this decision wasn't widely OK'd. There's even anticipation of people complaining about this. I think the reason this was OK'd was because this library is now provided as part of pipewire, so if a system uses pipewire, it should also have jack, which is most systems, especially those that play audio. Should we just remove our workaround? Thoughts welcome.

[tresf]

Ok, I've decided to keep our workaround for now at least.. and include another workaround for the missing libdb dependency. PR is up:

• Fix libjack.so.0 detection for openSUSE #7690