Package Details: webkit2gtk 2.50.6-7

Git Clone URL: https://aur.archlinux.org/webkit2gtk.git (read-only, click to copy)
Package Base: webkit2gtk
Description: Web content engine for GTK
Upstream URL: https://webkitgtk.org
Licenses: MIT, ISC, OFL-1.1, ICU, Apache-2.0, NCSA, BSD-3-Clause, BSD-2-Clause, BSL-1.0, MPL-1.1, MPL-2.0, GPL-2.0-only, LGPL-2.1-or-later, LGPL-2.1-only, BSD-2-Clause-Views, Apache-2.0 WITH LLVM-exception, AFL-2.0 OR GPL-2.0-or-later, BSD-Source-Code, bzip2-1.0.6, GPL-3.0-only WITH Autoconf-exception-3.0, GPL-3.0-or-later WITH Bison-exception-2.2, NCSA OR MIT, SunPro, Unicode-TOU
Provides: libjavascriptcoregtk-4.0.so, libwebkit2gtk-4.0.so
Submitter: andreas_baumann
Maintainer: andreas_baumann
Last Packager: andreas_baumann
Votes: 19
Popularity: 11.36
First Submitted: 2026-04-10 12:35 (UTC)
Last Updated: 2026-04-28 16:18 (UTC)

Sources (2)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »

mesaprotector commented on 2026-05-05 07:44 (UTC)

Was able to get through this with 16GB RAM, 16GB swap on 12 threads, though with an OOM about a quarter of the way through that might have been avoided had I been less cavalier about opening applications.

I still think I'll take a -bin package next time it updates though.

Scottaroo commented on 2026-05-03 18:07 (UTC) (edited on 2026-05-03 18:10 (UTC) by Scottaroo)

Greetings:

Just wanted to share some information for people who are having issues getting this package to build. The build process requires a fair amount of memory. If you have followed the standard recommendations for building packages, you have the following line in your /etc/makepkg.conf file:


MAKEFLAGS="-j$(nproc)"

This allows makepkg to create a number of threads equal to the number of processors reported by nproc on your system. Each compiler process requires a certain amount of memory, and it is very easy to start so many compiler processes that your system runs out of memory. From some experiments, I would say that you will need at least 2GB of RAM per process you start, but most of your RAM will be used and you will be swapping. A safer limit would be 4GB per process. Instead of letting makepkg base the number of processes on the number of cores you have, set it based on the amount of RAM you have. Divided the amount of RAM you have (in GB) by 4 (or 2 if you're feeling lucky) and temporarily set the number of cores for makepkg to use to a lower value in /etc/makepkg.conf:


## MAKEFLAGS="-j$(nproc)"
MAKEFLAGS="-j4"

and build the packages. It will obviously take somewhat longer, but it won't run the system out of memory causing the builds to fail.

Once the package is built, you can return the number of processors to normal value and go on about your day.

Best of luck.

Grzzlwmpf commented on 2026-05-03 12:04 (UTC) (edited on 2026-05-03 12:05 (UTC) by Grzzlwmpf)

Trying to build this fails if the user has set -fuse-ld= in LDFLAGS themselves – the PKGBUILD unconditionally appends -fuse-ld=lld and clang apparently doesn't have a strategy to deal with getting supplied two of these flags at once. The comment mentions upstream preferring clang because of optimizations, but I'd assume that mostly matters for the compilation itself, not for linking.

I assume lld is primariliy used here to speed up the linking process, but I'd argue that if a user has manually set a different linker, it's in all likelyhood already a faster one like mold or even lld itself. It'd probably be a good idea to only append that flag conditionally:

if [[ $LDFLAGS != *"-fuse-ld="* ]]; then
  LDFLAGS+=" -fuse-ld=lld"
fi

((naturally, there might be issues when using a different linker, but considering that the build will definitely fail otherwise I think that's an acceptable risk))

Lancaban commented on 2026-04-30 10:59 (UTC)

@fabiololix: and yet with webkit2gtk-4.1 installed already I can't remove webkit2gtk because it insists that it's a required dependency for Bambustudio-Bin. If I remove bambustudio and web2gtk, and try to re-install bambustudio, with webkit2gtk-4.1 already installed, it still insists on trying to pull/install webkit2gtk

As of this moment the Fedora based appimage will not launch on my system at all, the Ubuntu appimage launches, but has errors. These are obviously issues with bambustudio not Webkit2gtk, suffice to say as the end user it's still my problem to solve.

I'll try the swap file, hadn't thought of that. Thank you!!!

FabioLolix commented on 2026-04-29 21:39 (UTC)

The only appimages on their github are built for Fedora and Ubuntu specifically. In the past they've not worked on Arch for me. Which is why I'm here, on the AUR, because I'm using the bambustudio-bin

bambustudio-bin use the Fedora appimage as source and bambustudio-appimage use the Ubuntu appimage as source; the Ubuntu appimage use webkit2gtk-4.1

Still no luck compiling this beast

I had the same problem last year with other pkgbuilds and solved by creating a swap file of the same size of the installed RAM https://wiki.archlinux.org/title/Swap#

Lancaban commented on 2026-04-29 12:02 (UTC)

@fabiololix "Lancaban on bambustudio-appimage page comments it is reported that it work with webkit2gtk-4.1"

The only appimages on their github are built for Fedora and Ubuntu specifically. In the past they've not worked on Arch for me. Which is why I'm here, on the AUR, because I'm using the bambustudio-bin, from the AUR. It pulls webkit2gtk as a dependency see here - https://aur.archlinux.org/packages/bambustudio-bin#comment-1057610 - It specifically will NOT work with webkit2gtk-4.1

Still no luck compiling this beast.

moormaster commented on 2026-04-28 20:02 (UTC)

@andreas_baumann, you are right, the changes are in git - the aurweb just doesn't show them right now. Never mind.

Lancaban commented on 2026-04-28 17:56 (UTC)

Still no luck,

manually deleted the cache from /cache/yay Told it to do a clean build.

got to [4159/8506] and then Ram maxed out, started getting errors "Linux kernel, Memory shortage avoided, such-and-such program has been terminated by the Linux kernel because the system is low on memory."

it then cascades through 90% of any open programs, the system grinds to a halt, and completely fails

un_pogaz commented on 2026-04-28 16:24 (UTC)

Maybe remove the AUR cache to force a reimport from scratch. I have 32 Gb too and it run fine.

andreas_baumann commented on 2026-04-28 16:19 (UTC)

strange, i pushed, now several times. I see the change when I do trizen -G webkit2gtk. The webinterface of AUR and cgit are still showing the old version.

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »