Skip to content

Fix libwebkit deployment #37

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 17 commits into from
Closed

Conversation

probonopd
Copy link
Contributor

@probonopd probonopd commented Oct 10, 2022

@TheAssassin I am not the author of this but I thought maybe you'd like this to be upstreamed.
Please see tauri-apps/tauri#2940 for details.

Copy link
Member

@TheAssassin TheAssassin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Will consider merging, but it'll take some work to fix. There's a few hacks in there that won't work upstream (e.g., forcing GTK versions).

@FabianLars
Copy link

Heyy author here👋 tldr: can't recommend merging ✌️

This was really "tailored" for tauri's use-case and even for us it's not working great yet.

The only no-brainer in my eyes (which i meant to upstream but forgot) is the GTK_PATH change which fixes error messages along the lines of Gtk-Message: Failed to load module X, see the PR for a little more info about this change: tauri-apps#2

Then some changes where for fedora support (and arch etc) and i'm not sure if that's something interesting for upstream when you can't bundle redistributable appimages with linuxdeploy on arch/fedora (because of glibc and whatever) 🤷 So i didn't consider upstreaming these changes, especially since they weren't explicitly tested much (tho there were no complaints either)

The libwebkit specific changes at the bottom where only tested with webkit 4.0 / gtk3 and may not work with 4.1 or 5.0 / gtk4. Also i'm not sure how good of an idea it is to bundle (all) webkit files for all gtk apps?

The gio stuff is still broken, simple as that. The most prominent issue was something about certificates which renders webkitgtk unable to load https pages.

@FabianLars
Copy link

Oh and i forgot the most important issue here, this PR alone is not enough to make webkit work in appimages, it is missing the essential part of 2940 - the additional webkit files WebKitNetworkProcess WebKitWebProcess and libwebkit2gtkinjectedbundle.so - this was what 2940 was all about.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It adds regressions, and you are not using functions like get_pkgconf_variable() and copy_tree().
Please improve this.

@@ -86,7 +86,8 @@ search_tool() {
done
}

DEPLOY_GTK_VERSION="${DEPLOY_GTK_VERSION:-0}" # When not set by user, this variable use the integer '0' as a sentinel value
#DEPLOY_GTK_VERSION="${DEPLOY_GTK_VERSION:-0}" # When not set by user, this variable use the integer '0' as a sentinel value
DEPLOY_GTK_VERSION=3 # Force GTK3 for tauri apps

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you hardcoded DEPLOY_GTK_VERSION? You can set DEPLOY_GTK_VERSION=3 as an environment variable.

@@ -119,6 +120,8 @@ if [ "$APPDIR" == "" ]; then
fi

mkdir -p "$APPDIR"
# make lib64 writable again.
chmod +w "$APPDIR"/usr/lib64 || true

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not get it. As this point, $APPDIR is an empty directory, without usr inside.
Also, I am not a big fan of hardcoded /usr/lib64: it will not work on 32-bit distros. Furthermore, Debian-based distros use multiarch so there is no /usr/lib64.

@@ -203,15 +206,15 @@ case "$DEPLOY_GTK_VERSION" in
echo "Installing GTK 3.0 modules"
gtk3_exec_prefix="$(get_pkgconf_variable "exec_prefix" "gtk+-3.0")"
gtk3_libdir="$(get_pkgconf_variable "libdir" "gtk+-3.0")/gtk-3.0"
gtk3_path="$gtk3_libdir/modules"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand, the issue is /modules should not be at the end of gtk3_path. In that case, why didn't you just remove /modules at the end to fix the issue?

@@ -305,3 +308,19 @@ for directory in "${PATCH_ARRAY[@]}"; do
ln $verbose -s "${file/\/usr\/lib\//}" "$APPDIR/usr/lib"
done < <(find "$directory" -name '*.so' -print0)
done

# set write permission on lib64 again to make it deletable.
chmod +w "$APPDIR"/usr/lib64 || true

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/usr/lib64 is 755 on systems. I think the issue is how you create this directory before calling linuxdeploy.

chmod +w "$APPDIR"/usr/lib64 || true

# We have to copy the files first to not get permission errors when we assign gio_extras_dir
find /usr/lib* -name libgiognutls.so -exec mkdir -p "$APPDIR"/"$(dirname '{}')" \; -exec cp --parents '{}' "$APPDIR/" \; || true

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like you are trying to perform a copy_tree, isn't it?

# related files that we seemingly don't need:
# libgiolibproxy.so - libgiognomeproxy.so - glib-pacrunner

gio_extras_dir=$(find "$APPDIR"/usr/lib* -name libgiognutls.so -exec dirname '{}' \; 2>/dev/null)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not safe, it can returns multiples directories, like:

/usr/lib/gio/modules
/usr/lib32/gio/modules

Use "$(get_pkgconf_variable "giomoduledir" "gio-2.0") instead.

EOF

#binary patch absolute paths in libwebkit files
find "$APPDIR"/usr/lib* -name 'libwebkit*' -exec sed -i -e "s|/usr|././|g" '{}' \;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From where libwebkit pops up? I do not see any copy of this library before.

@FabianLars
Copy link

[...] Please improve this.

As i said, our branch and most of these changes are not upstreamable. And especially since our bundler directly downloads the live version of our fork i will not make many changes to it.

@TheAssassin
Copy link
Member

Closing this PR for now, since as @FabianLars pointed out this has never meant to go upstream. If we find useful changes, I'm sure @FabianLars won't mind their inclusion. I also want to restate that PRs are very welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants