webkitgtk hook fails if multiple webkitgtk versions are installed

[FabianLars]

Ref #5 (cc @Samueru-sama )

When users have more than one of webkitgtk 4.0, 4.1, and 6.0 installed, which is somewhat likely outside of CI envs, the script fails with

/home/fabianlars/.cache/tauri/lib4bin-x86_64: line 636: [: /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0: binary operator expected

Assuming that this error means that sys_webkit_lib_dir is not a single dir, imo it would be fine to simply include all of them considering the very small size of the files in question (but wouldn't mind if it could detect the version from the .so file or something).

I'm not that familiar with bash scripts so i'm not very confident in fixing this myself but if nobody else has fixed (or closed it as wontfix) i'll try to take a stab at it anyway once my use case has gotten past the proof-of-concept stage.

[Samueru-sama]

That's odd, lib4bin works by checking the libraries that are linked or dlopened, and based on that it tries to find the webkit2gtk-* directory.

Or am I reading this wrong and the issue is when lib4bin tries to copy the webkit2gtk dir that because there are multiple it fails to do so?

In any case if it is the later case how does the CI end up with multiple webkit2gtk directories? WIth the PrusaSlicer appimage of probono I had to update it to use webkit2gtk 4.1 because there was no 4.0 on the ubuntu 24.04 repos.

I'm not that familiar with bash scripts so i'm not very confident in fixing this myself but if nobody else has fixed (or closed it as wontfix) i'll try to take a stab at it anyway once my use case has gotten past the proof-of-concept stage.

I think what can be done is bundle the webkit2gtk directory with the same version number as the library in the AppDir, not sure what @VHSgunzo thinks about adding all of them to the AppDir.

[Samueru-sama]

One issue with adding all of them to the AppDir is that the helper binaries have the same names, or at least they do for webkit2gtk 4.0 and 4.1.

sharun works by wrapping the binary, it calls the ld-*.so in the AppDir, gives the shared/$LIB directory to --library-path and finally tells the ld-*.so to launch the respective binary, this way we avoid having to patch a relative interpreter which is the other way this issue is fixed.

so that means we can't have the same binaries with the same name in shared/bin we would need to use multiple instances of sharun in the AppDir.

---

Worst case scenario you can ignore all the lib4bin hooks (not use the -k flag), and on every binary in shared/$LIB run

patchelf --set-interpreter "./shared/lib/ld-linux-x86-64.so.2" /path/to/bins/in/lib
ln -s ./x86-64-linux-gnu ./ in the shared/lib

The issue with using a relative interpreter is that you have to change the current working directory to the AppDir, which already needs to be done due to the patching done in the webkit2gtk libs anyway.

[FabianLars]

thanks for the fast response :)

Or am I reading this wrong and the issue is when lib4bin tries to copy the webkit2gtk dir that because there are multiple it fails to do so?

yep

In any case if it is the later case how does the CI end up with multiple webkit2gtk directories? WIth the PrusaSlicer appimage of probono I had to update it to use webkit2gtk 4.1 because there was no 4.0 on the ubuntu 24.04 repos.

CI is fine in most cases i assume. For Tauri's use case we have to deal with users running it on their own machines though (mostly for testing, but too often for distribution...). In 22.04 a user could have all 3 versions, in 24.04 there's still 4.1 and 6.0.

[...]
so that means we can't have the same binaries with the same name in shared/bin we would need to use multiple instances of sharun in the AppDir.

ah right, got it.

Worst case scenario you can ignore all the lib4bin hooks (not use the -k flag), and on every binary in shared/$LIB run
[...]

At that point i'd probably just hardcode the webkit folder name that i need instead x)

[Samueru-sama]

For Tauri's use case we have to deal with users running it on their own machines though (mostly for testing, but too often for distribution...). In 22.04 a user could have all 3 versions, in 24.04 there's still 4.1 and 6.0.

Alright but the AppImage should only have one instance of webkit2gtk. Doesn't matter what versions the user has installed or if any at all.

At that point i'd probably just hardcode the webkit folder name that i need instead x)

Do you mean compile webkit2gtk? Note that the lib patching can be avoided if webkit2gtk gets compiled with developer mode, which lets the env variable WEBKIT_EXEC_PATH be used. and that way the lib patching is avoided all together.

[VHSgunzo]

When users have more than one of webkitgtk 4.0, 4.1, and 6.0 installed, which is somewhat likely outside of CI envs, the script fails

@FabianLars @Samueru-sama
Hi! Check the fixed lib4bin from main

[VHSgunzo]

v0.2.7...v0.2.8

v0.2.8

[FabianLars]

Alright but the AppImage should only have one instance of webkit2gtk. Doesn't matter what versions the user has installed or if any at all.

With users i meant developers using Tauri, sorry.

Do you mean compile webkit2gtk? Note that the lib patching can be avoided if webkit2gtk gets compiled with developer mode, which lets the env variable WEBKIT_EXEC_PATH be used. and that way the lib patching is avoided all together.

nono, i meant changing the lib4bin script for my usecase in our distribution of it to make it only care about 4.1 (or 6.0 soon). Compiling webkitgtk isn't an option for us sadly.

Hi! Check the fixed lib4bin from main

This seems to work as far as i can tell, thanks!

[Samueru-sama]

In 22.04 a user could have all 3 versions, in 24.04 there's still 4.1 and 6.0.

Btw @FabianLars you should only use 24.04 or newer to make appimages this way.

The reason is that on 22.04 and likely older there is a bug in mesa that prevents the proprietary nvidia driver from working

[FabianLars]

Noted