App can't launch when build with KDE SDK 6.8

[matterhorn103]

Hi, I am helping to maintain the org.openchemistry.Avogadro2 Flatpak of Avogadro. I’m having an issue and was hoping someone might be able to provide some help or advice as to what’s going on.

Our beta branch is currently building against version 6.7 of the KDE runtime, but we’d like to bump it to 6.8, see my PR here. Running the beta with 6.8 using flatpak run --runtime-version=6.8 org.openchemistry.Avogadro2//beta works fine (haven’t checked everything in detail but it starts correctly), but running the test build created by Buildbot^[1] results in the error:

$ flatpak run org.openchemistry.Avogadro2//test
avogadro2: error while loading shared libraries: libAvogadroQtOpenGL.so.1: cannot open shared object file: No such file or directory

Over on the KDE discourse the announcement from @bbhtt included the note that

@bbhtt

Please note that if you are building something against the 6.8 runtime, use only the latest Flatpak Builder 1.4.4.

Details

On Freedesktop runtime 24.08 we did some changes to Cmake libdir configuration that instructed apps to use /app/lib as the install path.

This was previously a patch to Cmake in Freedesktop SDK, but in 24.08 we dropped that patch and instead set CMAKE_INSTALL_LIBDIR in Flatpak Builder.

So this clearly had an effect on the way that Avogadro is being bundled; the beta branch has everything in /app/lib whereas this test branch has stuff split between /app/lib and /app/lib64, and the library that can’t be loaded is now in the latter.

The thing is, I don’t know why this should break the Flatpak; a normal local non-Flatpak build (against Qt 6.8) also splits things between lib and lib64, but the resulting binary launches absolutely fine.

The manifest doesn’t have anything weird in it I don’t think. It uses builddir: true and no-make-install: true because the umbrella project doesn’t have install command defined, which means there’s a post-install step where the entire prefix directory is copied into /app. But I don’t see why those things should pose an issue.

Is it maybe incorrect to use /app/lib64 with a Flatpak?

---

1. Downloadable using flatpak install --user https://dl.flathub.org/build-repo/145201/org.openchemistry.Avogadro2.flatpakref ↩︎

[bbhtt]

The idea is that /app/lib64 should not exist, everything should go to /app/lib.

My guess is since most of your dependencies are vendored, when flatpak-builder sets -DCMAKE_INSTALL_LIBDIR="lib", avogadro is consuming the value but it is not being passed down the chain to the individual libraries, which is why they are ending up the upstream cmake default of /app/lib64.

Previously this was working because cmake inside the runtime was itself patched, but now it is using the cmake arg.

The solution is to devendor the individual libraries and build them as separate modules or set --env=LD_LIBRARY_PATH=/app/lib64 or symlink everything from /app/lib64 to /app/lib.

[matterhorn103]

Ah I see, thanks very much for both the explanation and suggested fixes!