Carla not detected on openSUSE with lmms-1.2.0-rc6-linux-x86_64.AppImage

[geckolinux]

Hi there, I'm running openSUSE Tumbleweed and Leap 15.0 with carla and carla-vst installed at version 1.9.7+git20171111.5b97ec1e-50.14. The latest lmms-1.2.0-rc6-linux-x86_64.AppImage doesn't detect Carla being installed:

Cannot load library /tmp/.mount_lmms-1bfmTqI/usr/lib/lmms/libcarlabase.so: (libcarla_standalone2.so: cannot open shared object file: No such file or directory)
Cannot load library /tmp/.mount_lmms-1bfmTqI/usr/lib/lmms/libcarlarack.so: (libcarlabase.so: cannot open shared object file: No such file or directory)
Cannot load library /tmp/.mount_lmms-1bfmTqI/usr/lib/lmms/libcarlapatchbay.so: (libcarlabase.so: cannot open shared object file: No such file or directory)

Thanks a lot for developing LMMS, it's fantastic!

[geckolinux]

Also, I just tried lmms-1.2.0-rc5-linux-x86_64.AppImage, and it does detect Carla.

[SecondFlight]

Looks like a regression. Tagging @PhysSong, sounds like this should be looked into before the 1.2 release.

[geckolinux]

Thanks @SecondFlight for looking into it.

[Bleuzen]

Same on Manjaro. AppImage doesn't seem to detect Carla. Self compiled rc6 does.

[PhysSong]

It looks like the bug in package_linux.sh.in, but the AppImage worked fine because of an upstream bug, probonopd/linuxdeployqt#289.
Upstream fixed the issue via probonopd/linuxdeployqt@c17e3f0, and now our bug is an issue.

linuxdeployqt creates AppRun symlink to the executable file. Due to the linuxdeployqt bug, it was a link to lmms, which is the wrapper script. After the bug was fixed, however, it links to lmms.real so the script never runs.

@tresf I think we should remove the problematic symbolic link and manually create desired one. I also wonder why we substitute the Exec entry back to lmms after running linuxdeployqt.

Not much related to this issue, but I think we may consider bundling Carla and using it when missing.

[tresf]

It looks like the bug

Bug? No, it's how we were told to use the script by @probonopd. It's here: #3688 (comment)

Without it, the whole foo.real trick is worthless.

I think we should remove the problematic symbolic link and manually create desired one.

Probably, but this is the third time we've had to write additional logic like this because upstream changed their mind.

I also wonder why we substitute the Exec entry back to lmms after running linuxdeployqt.

It's an order of operations problem. We need to inject some runtime information at LMMS launch, and we need to have our own script for that, but the linking tool needs it by its original name to bundle all of the dependencies. The hack -- which I had originally questioned but also which is now considered a bug -- allows the tool to ignore the .real extension at bundle time. I'm not sure how we're supposed to do this. I'll let @probonopd chime in, we can't be the only project needing fine-grained control over the launcher.

Not much related to this issue, but I think we may consider bundling Carla and using it when missing.

Yes off-topic and it should probably be put on the back burner because AFAIK it would have to be done by hand. The Carla scripts rely on Python3-Qt4 but AppImage doesn't yet have support for bundling the scripting framework by pointing to a script file (and we probably don't want to), so it's simply too complex to ship in an AppImage for now. Long-term, if Carla's launch support were part of it's main executables I suspect AppImage would bundle it without much fuss.

[tresf]

I'll quote my message to the linuxdeployqt project...

So some additional background on all of this...

• When we started integrating linuxdeployqt it was strongly encouraged to use the .desktop file as the source of the bundle -- but -- we found it didn't work properly with custom Exec= commands, e.g. ones that touch the environment before launching. In our case, it was an environmental variable for QT that we needed to set (something we'd consider and edge-case).
• We used the foo.real shim and linuxdeployqt automagically found our binary and everything worked
• Then, later, as we started to hit very specific issues with the .AppImage format, such as non-relocatable JACK libraries and other shims such as specific, nested folders that weren't being added to the LD_LIBRARY_PATH, we continued using this shim and it's been an important part of how we launch our software.

So, the root of the issue was the first environmental variable -- but -- the need to add more has made this just-in-time-custom-environment much more important as we embrace .AppImage as our preferred portable format (as a benchmark, our current release has 16,000 downloads in 2 months -- we consider .AppImage a success).

So what we need is the ability to shim custom logic into the launcher from the AppRun and it doesn't need to be obscure, we just need to know how we should tackle this problem. Although it started with an edge-case, the need to keep custom launch logic in some form -- I would expect -- is much more widely required by other projects.

We'd be happy to provide this as a supplement to the .desktop specification (e.g. ExecAppImage=foo.shim) but since we're still volatile (probonopd/linuxdeployqt#227) to a Continuous release, we can't release until we have a viable solution.

[probonopd]

Can you use foo_real instead of foo.real?

[PhysSong]

We need a wrapper script to setup proper environment and used to use .real trick. I think the file name doesn't matter so much. We can use lmms_real as well as lmms.real, but we still want AppRun to point lmms, the wrapper script.
If that's impossible, we can manually recreate the symbolic link or replace AppRun with the wrapper script(I guess some modification is needed).

[PhysSong]

@probonopd As @tresf said, we used to use probonopd/linuxdeployqt#289 as a feature. The problem is not the dot, but the fact that we can't leverage from the bug anymore.
I think it'd be nice if linuxdeployqt provides a way to use a wrapper script easily, though we can work around this on our side.

[tresf]

though we can work around this on our side.

Done via 69ed110. It was a one-liner. ln -sfr "${APPDIR}/usr/bin/lmms" "${APPDIR}/AppRun". Building an AppImage now. Will upload for testing.

[PhysSong]

Building an AppImage now.

Actually, I built one with an almost identical patch. Just tested it and works fine.

[tresf]

Build available here: https:/tresf/lmms/releases/download/v1.2.0-RC7/lmms-1.2.0-rc4.302-linux-x86_64.AppImage

Don't let the version number mislead you, it's a bug with our versioning logic when on a fork, this is latest stable-1.2.

[PhysSong]

FYI, I just replaced official AppImage with working version.

[tresf]

Thanks. Makes sense, hate to cause all sorts of bug reports.

[geckolinux]

Awesome thanks very much!