Chataigne
Chataigne copied to clipboard
benkuper
AppImage missing required library
Hi @benkuper, thanks for making this interesting application available as an AppImage for Linux. Currently it is missing a library which should (along with its dependencies) be bundled inside the AppImage:
Chataigne: error while loading shared libraries: libwebkit2gtk-4.0.so.37: cannot open shared object file: No such file or directory
Reference: https://github.com/AppImage/appimage.github.io/pull/2020
hey @probonopd , reply a bit late, sorry... The AppImage has been made to be usable with off-the-shelf Ubuntu distribution. Unfortunately I don't have time to dig into other distros compat, but any pull-request is welcome !
Which version of Ubuntu?
Seems you are linking to very specific library versions. It would ultimately be better to either statically compile the application with those libs, or to include them inside the Appimage.
At the moment it's impossible to use the Appimage on Debian Stable (11) for instance.
Again, any pull request is welcome :) but I don't have time to work on this right now.
I am having this same issue - and I'd like to help if I can.
I understand that you don't have time to resolve this issue. But I'm not sure how to help you.
Can you tell me what you need in your pull request? If I can do that, I'd be happy to - but don't know how!
Thank you. And thank you for creating and sharing this incredible software!
Hello ! I'm replying here since I think I'm the last person having worked on the Linux CI / AppImage generation :)
Basically, any lib that has to be bundled along with Chataigne should be placed in this directory : https://github.com/benkuper/Chataigne/tree/master/Builds/LinuxMakefile/Chataigne.AppDir/usr/lib In a perfect world the RPi versions (in Builds/Raspberry and Builds/Raspberry64) should receive the same libs. But IIRC Chataigne was working on a fresh Raspberry Pi OS install last time I checked so it may not be necessary.
Then the AppImage is generated automatically on each push using Github actions, the workflow is here : https://github.com/benkuper/Chataigne/blob/master/.github/workflows/build.yml
As you can see the CI is running on an ubuntu 22.04 machine.
So to answer your question : what's needed here is to identify the missing libs (and dependencies), download them from e.g the Ubuntu or Debian package repo with the correct architecture (x86_64) and add them to the AppDir /usr/lib. You can try to generate the AppImage manually (following the same command lines as in the CI workflow) before doing a PR to make sure that there are no dependencies missing.
Thanks for helping !
Thanks, Tom.
I...almost understand. :)
I'm new to github and to AppImage, but I have lots of experience with Linux and with Debian. I might be able to be helpful!
I'll see what I can do.
It looks like it is unhappy about libssl.so.3 (Debian 12 is using libssl.so.1.1) and libcrypto (included in libssl?).
I tried the suggested "ln -s" solution, which made it complain about glibc - and about not finding OPENSSL_3.0.0. :)
Clearly that will not work.
I see that Debian is moving to newer versions of both openssl and glib. I wonder if that will solve the problem, at least for Debian 11?
https://tracker.debian.org/pkg/openssl https://tracker.debian.org/pkg/glibc
I have Debian Unstable is a VM. I'll try the Chataigne AppImage there, and see if it just works.
Thanks.
OK, so here is what I learned.
The AppImage doesn't work on Debian 11 (Bullseye/Stable). Several packages are too old, as I described.
However, the AppImage seems to work perfectly with Debian 12 (Bookworm/Testing). Woo!
Since Bookworm will be released soon, it could be that you don't need to do anything, and the AppImages will just work.
But if I can help in some way, I'm totally wiling.
Well, generally it is best practice to compile software for the oldest systems user might still be using, not for the newest ones. This way, users (who usually don't run the latest of everything) can still use the software.
Except When new OS versions break compatibility with the previous ones... I tried to find a way to have openssl dependency work on both 20.04 and 22.04 and couldn't find a way. I decided that the latest versions would be the safest bet to not have to deal with this too soon.
Except When new OS versions break compatibility with the previous ones.
That must not happen and would be a bug in the operating systems. Operating systems (and the core libraries in them) must be backward compatible, which means, never break existing applications. Occasionally this happens, but I consider these occasions exceptions that need to be discussed with whoever caused the breakage.
@probonopd Thanks for your insight. Do you have any suggestion on how to handle this libssl version update? I can try to find some time soon to work on it.