Closed MMarco94 closed 1 month ago
If you stumble upon this issue, I "fixed" it with this workaround: https://github.com/MMarco94/tambourine-music-player/commit/26c9ad94b3464f12c6b4424aaae9c7041f79a7c2#diff-f00c79f3c8561c247ce8bbc1d341adc99052cad33d02b7e328b8ec21d4b35329
@MMarco94 I am not sure, what's wrong with extracting skiko during packaging?
Compose Gradle plugin also extracts in Compose Gradle plugin, when packaging an application. The generated launcher passes the directory, containing skiko, by adding -Dskiko.library.path=...
to the JVM args.
Thanks for the pointer! I'll definitely look into how to better package my application.
However, I think the bug still stands. I'm packaging the app with the packageUberJarForCurrentOS
task, and I think it should still work on a read-only home directory.
What other library do is unpackage the native binary on a temporary folder instead of the home.
Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.
Library.kt unpacks
libskiko-linux-x64.so
on the home directory.That's not allowed when running the app on Linux inside a Flatpak container, so Skiko won't initialize.
To reproduce, you need to run the app in a Flatpak container that either:
libskiko-linux-x64.so
hasn't been unpacked previouslyAn example of a stacktrace is: