AppImage: Don't set LD_LIBRARY_PATH

[tresf]

Our AppRun script historically sets LD_LIBRARY_PATH to a sane location (e.g. the contained usr/lib) but this pollutes the dynamic loader for child processes, such as glibc's hwcaps, which can crash certain system calls that rely on the dynamic link loader (such as some calls that occurs when loading our RemoteVstPlugin.exe.so)

Closes #7684

[messmerd]

With this PR on Linux Mint 22:

Carla appears to be installed on this system at /usr/lib[64]/carla so we'll use it.
Jack appears to be installed on this system, so we'll use it.
Lv2 plugin SUMMARY: 18 of 40  loaded in 90 msecs.
For details about not loaded plugins, please set
  environment variable "LMMS_LV2_DEBUG" to nonempty.
"Cannot load library /tmp/.mount_lmms-1WS2hqN/usr/lib/libcarlabase.so: (/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_dir_unref)"
"Cannot load library /tmp/.mount_lmms-1WS2hqN/usr/lib/libcarlapatchbay.so: (/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_dir_unref)"
"Cannot load library /tmp/.mount_lmms-1WS2hqN/usr/lib/libcarlarack.so: (/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_dir_unref)"

The last 3 lines are not printed when using the AppImage from the master branch. However, Carla still works despite the error messages.

[tresf]

Tested:

• ✅ PASS: Manjaro 24 (VST32, Zyn)
• ✅ PASS: Ubuntu 24.04 (VST32, VST64, Zyn)

[tresf]

"Cannot load library /tmp/.mount_lmms-1WS2hqN/usr/lib/libcarlabase.so: (/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_dir_unref)"

The last 3 lines are not printed when using the AppImage from the master branch. However, Carla still works despite the error messages.

Thanks for testing. Same on Ubuntu 24.04. I'm a bit confused by this error because those libraries specifically don't link directly against libgobject-2.0.so.0. Furthemore, I would expect this to break Carla and for some reason it doesn't.

Setting export LD_DEBUG=libs doesn't help much either, but from what I can find online, this may be a python-ism, so perhaps we can shim the plugin loading to help, I'm just afraid that as soon as we mess with LD_LIBRARY_PATH, we could potentially cause the same exact VST issue that inspired this patch.

[tresf]

I'm a bit confused by this error because those libraries specifically don't link directly against libgobject-2.0.so.0. Furthemore, I would expect this to break Carla and for some reason it doesn't.

The error is caused during the plugin scanning. This is the call stack:

-> libcarlapatchbay +
                    |
                     -> libcarlabase +
                                     |
                                      -> /usr/lib/carla/libcarla_native-plugin.so +
                                                                                  |
                                                                                   -> /lib/x86_64-linux-gnu/libgobject-2.0.so.0

The error is misleading because the symbol g_dir_unref DOES exist in /lib/x86_64-linux-gnu/libgobject-2.0.so.0 and /usr/lib/carla/libcarla_native-plugin.so DOES prefer to load this version, however the error goes away if LD_LIBRARY_PATH is set to our own usr/lib folder, so this error is very confusing to troubleshoot.

Things I've tried:

• I've tried loading our copy of libgobject-2.0.so.0 using QLibrary before scanning, hoping it'll be cached. (didn't fix this)
• I've tried omitting the plugin scanner from loading anything with sf2 or suil in the name -- since they too would load our copy of libgobject (it doesn't work)-- but again -- this test is flawed since the error goes away when OUR copy is forced using LD_LIBRARY_PATH=$DIR/usr/lib in our launcher.
• I've tried setting LD_LIBRARY_PATH to our own usr/lib directory using C++ setenv, but this did not help.
• I've tried manually setting @rpath on usr/lib/libcarlabase.so

Some observations...

• Despite the error in the console, the plugin does load. This can be observed by adding the following to PluginFactory.cpp after QLibrary.load() is called:

		if (! library->load()) {
			m_errors[file.baseName()] = library->errorString();
			qWarning("%s", library->errorString().toLocal8Bit().data());
			continue;
		}
+		qDebug() << "PluginFactory: Loaded: " << file.absoluteFilePath();

"Cannot load library /media/psf/Home/Downloads/LMMS.AppDir/usr/lib/libcarlabase.so: (/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_dir_unref)"
"Cannot load library /media/psf/Home/Downloads/LMMS.AppDir/usr/lib/libcarlapatchbay.so: (/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_dir_unref)"
"Cannot load library /media/psf/Home/Downloads/LMMS.AppDir/usr/lib/libcarlarack.so: (/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_dir_unref)"
[...]
PluginFactory: Loaded:  "/media/psf/Home/Downloads/LMMS.AppDir/usr/lib/libcarlapatchbay.so"
[...]
PluginFactory: Loaded:  "/media/psf/Home/Downloads/LMMS.AppDir/usr/lib/libcarlarack.so"
[...]
PluginFactory: Loaded:  "/media/psf/Home/Downloads/LMMS.AppDir/usr/lib/libcarlabase.so"

[tresf]

After a long conversation with @messmerd on Discord, we've decided to attempt to leverage LD_PRELOAD in our launcher in an attempt to suppress the errors created by the loading of libcarlabase.so --> libcarla_native-plugin.so. LD_PRELOAD allows us to specify single library overrides without polluting the entire LD_LIBRARY_PATH.

Due to the logic involved to do this responsibly, i.e:

• Don't set LD_PRELOAD on systems without Carla
• Don't set LD_PRELOAD on systems that contain a different version of this library from the one we bundle

... this conditional logic caused our poor launch_lmms.sh script to grow even larger in size and ultimately a bit harder to keep organized and to maintain.

However, due to the apprun-hooks plugin system offered by linuxdeploy, we're able to refactor launch_lmms.sh (well, we removed it altogether) by moving our various scripted workarounds into self-contained script files (one-per workaround).

With regards to the longevity of this LD_PRELOAD workaround, I'm personally not extremely confident in this technique, since it could potentially cause unexpected issues with libraries that depend on libgobject-2.0.so.0 (or any others we decide to add in the future for similar reasons), however @messmerd seemed to favor a solution that did not cause startup errors, so that's the motivation and the ultimate decision for using this technique.

This PR is reading for testing and review.

[messmerd]

Haven't tested but the Carla hook looks good to me

[tresf]

Shellcheck is already scanning scripts in cmake, all scripts pass.
I've tested this on Manjaro, KDE Neon, Ubuntu 24.04, Ubuntu 22.04 and Ubuntu 24.04 ARM64, all pass.

The launcher looks like this now when run from terminal:

[carla-hook.sh] Carla appears to be installed on this system at /usr/lib/carla so we'll use it.
[carla-hook.sh] Preferring the system's "libgobject-2.0.so.0" over the version bundled.
[jack-hook.sh] Jack appears to be installed on this system, so we'll use it.

I've also tested our experimental .run installer using export CPACK_TOOL=makeself and it's picking up the new apprun-hooks properly as well.