Closed Risto-Stevcev closed 1 year ago
Thanks for the report!
i did a quick test (actually wasn't "quick". i'm not used to these old-school linux installers anymore 😅) and the issue seems to be that /usr/lib64 on void is just a symlink to /usr/lib. The appimage bundler only picks up the "real" file while webkitgtk is still looking for it at the symlink location ;/
p.s. these weird looking paths are correct, its working dir is <appimage>/usr
Edit: I'll assign myself for this issue for now but since i'll be busy over the weekend anyway it's okay (and encouraged) if someone else wants to take a look at it :) It's hopefully as simple as telling the cp
command to not follow symlinks...
@FabianLars Ah ok, thanks. I gave it a try on my system and I managed to get it to work with find -L
, but I've only tested it on Void Linux. I referenced the PR in case that fixes it without any changes.
Describe the bug
The AppImage build is giving a warning that it can't load the injected bundle for
webkit2gtk
. I tried debugging a bit by running the AppImage with the--appimage-mount
flag to inspect the squashfs, and from what I can tell, it's looking up the wrong path:././lib64/...
instead of./usr/lib64/...
. As a result, it can't find the bundled shared object, and it looks like it's falling back to the system-wide shared object instead. I haven't tested it on a linux system without the webkit2gtk dependency, but it looks like it's not self-contained based on the warning/error.Reproduction
Expected behavior
I think the warning shouldn't exist, and it should open the shared object file from the AppImage bundle instead of the system-wide one.
Platform and versions
λ uname -a Linux voidristo 6.1.27_1 #1 SMP PREEMPT_DYNAMIC Tue May 9 03:35:06 UTC 2023 x86_64 GNU/Linux