Package Details: webkitgtk 3:2.4.11-18

Git Clone URL: (read-only, click to copy)
Package Base: webkitgtk
Description: Legacy Web content engine for GTK+ 3
Upstream URL:
Licenses: custom
Conflicts: libwebkit3, webkitgtk3
Provides: libwebkit3=2.4.11, webkitgtk3=2.4.11
Replaces: libwebkit3, webkitgtk3
Submitter: City-busz
Maintainer: frealgagu
Last Packager: lfleischer
Votes: 60
Popularity: 0.51
First Submitted: 2017-06-30 07:40
Last Updated: 2019-11-23 15:07

Dependencies (21)

Sources (5)

Pinned Comments

frealgagu commented on 2019-04-14 18:13


Q: What's the difference between this package and extra/webkit2gtk?

A: webkitgtk/webkitgtk2 provides WebKit1 API/ABI, which is not compatible with WebKit2 API/ABI provided by extra/webkit2gtk. WebKitGTK+ 2.4.x is the latest branch that provides WebKit1 API. Later branches provides WebKit2 API only.

Please don't flag it as out-of-date.

Q: Are there binaries for this package somewhere?

A: We maintain built and signed packages at

Q: "error while loading shared libraries: cannot open shared object file: No such file or directory"

A: You'll need to rebuild against the latest version of ICU.

Q: "error: ‘WTF::StringImpl::StaticASCIILiteraicASCIILiteral’ has not been declared" or any enchant errors.

A: If you are building in parallel, try disabling parallel using -j1 in /etc/makepkg.conf

Q: Why building takes too long time?

A: WebKit is inherently big and complex. You can modify /etc/makepkg.conf or PKGBUILD directly to build it in parallel.

  • Change "make all stamp-po" by "make -j x all stamp-po" in PKGBUILD replacing x by cores your machine has. (Thanks to @MadMe)

  • Change /etc/makepkg.conf in that way: under # ARCHITECTURE, COMPILE FLAGS use MAKEFLAGS="-j9" # It should be one more than your virtual CPUs. (Thanks to @tuxsavvy).

However be pending if errors occur as mentioned in previous question.

Q: How much I want to wait to a successful compilation?

A: It varies of your PC's processor and RAM, the times shared in the comments are as follow:

  • 3.5 hours to build on core i5 laptop with 8G of RAM, makeflags j4. (@cabbage)

  • 13.5 hours to build on AMD Athlon X2, makeflags j1 (@Bonnietwin).

  • 5-6 hours on Core2Duo E8400 with 8GB RAM, makeflags j2 (tuxsavvy).

  • 50 minutes on 6c/12t 3.3GHz (@kubrick).

Latest Comments

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

regagain commented on 2018-02-06 15:48

It seems that the following dependencies are missing: automake, bison, flex.

Mikle_Bond commented on 2018-02-03 19:14

Noticed another problem. Same as @ShalokShalom commented below.

During compilation it throws a couple of type conversion errors like this: error: invalid conversion from ‘const JSChar {aka const short unsigned int}’ to ‘const UChar {aka const char16_t}’

I've found relevant ticket about it here , though it seems pretty old and it is strange I managed to face this issue...

There was suggested a workaround - to define those types explicitly trough preprocessor flag, and it worked for me like that: CPPFLAGS="-DUCHAR_TYPE=char16_t" MAKEFLAGS="-j4" makepkg -s

jasonhansel commented on 2018-01-31 00:37

Does not work with parallel make (e.g. MAKEFLAGS="-j4").

lano1106 commented on 2018-01-27 11:01

I have tried to recompile with the latest libenchant library and I got a new compile error that I didn't have previously. Any idea why I'm getting this:

CXX DerivedSources/WebCore/libWebCore_la-XLinkNames.lo DerivedSources/WebCore/MathMLNames.cpp:642:17: error: ‘WTF::StringImpl::StaticASCIILiteraicASCIILiteral’ has not been declared StringImpl::StaticASCIILiteraicASCIILiteral::s_initialFlags | (1069503 << StringImpl::StaticASCIILiteral::s_hashShift) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DerivedSources/WebCore/MathMLNames.cpp:644:39: error: redefinition of ‘WTF::StringImpl::StaticASCIILiteral WebCore::MathMLNames::msupData’ static StringImpl::StaticASCIILiteral msupData = { ^~~~~~~~ DerivedSources/WebCore/MathMLNames.cpp:616:39: note: ‘WTF::StringImpl::StaticASCIILiteral WebCore::MathMLNames::msupData’ previously defined here static StringImpl::StaticASCIILiteral msupData = { ^~~~~~~~ DerivedSources/WebCore/MathMLNames.cpp:651:39: error: redefinition of ‘WTF::StringImpl::StaticASCIILiteral WebCore::MathMLNames::mencloseData’ static StringImpl::StaticASCIILiteral mencloseData = { ^~~~~~~~~~~~ DerivedSources/WebCore/MathMLNames.cpp:427:39: note: ‘WTF::StringImpl::StaticASCIILiteral WebCore::MathMLNames::mencloseData’ previously defined here static StringImpl::StaticASCIILiteral mencloseData = { ^~~~~~~~~~~~ CXX DerivedSources/WebCore/libWebCore_la-XMLNames.lo DerivedSources/WebCore/MathMLNames.cpp: In function ‘void WebCore::MathMLNames::init()’ DerivedSources/WebCore/MathMLNames.cpp:935:67: error: ‘maligngroupData’ was not declared in this scope { (void)&maligngroupTag, reinterpret_cast<stringimpl*>(&maligngroupData) }, ^~~~~~~~~~~~~~~ DerivedSources/WebCore/MathMLNames.cpp:935:67: note: suggested alternative: ‘maligngroupTag’ { (void)&maligngroupTag, reinterpret_cast<stringimpl*>(&maligngroupData) }, ^~~~~~~~~~~~~~~ maligngroupTag DerivedSources/WebCore/MathMLNames.cpp:964:62: error: ‘mstyleData’ was not declared in this scope { (void)&mstyleTag, reinterpret_cast<stringimpl*>(&mstyleData) }, ^~~~~~~~~~ DerivedSources/WebCore/MathMLNames.cpp:964:62: note: suggested alternative: ‘mstyleTag’ { (void)&mstyleTag, reinterpret_cast<stringimpl*>(&mstyleData) }, ^~~~~~~~~~ mstyleTag make[1]: *** [GNUmakefile:64525: DerivedSources/WebCore/libWebCore_la-MathMLNames.lo] Error 1</stringimpl*></stringimpl*></stringimpl*></stringimpl*>

yan12125 commented on 2018-01-22 15:05

Announcement: If you got enchant errors, check the first two entries in my pinned FAQ comment.

Thermi commented on 2018-01-11 12:40

Why is the library file of the previous version only a couple MB in size then? It looks like this one builds a static library or includes a lot of other files into the library. Looks wrong to me.

Batou commented on 2018-01-02 02:58

@yan12125 thanks! For those wondering, I fixed it by just exporting a new PATH without /bin in it and then just running the pacaur. The other suggestion (editing PKGBUILD and setting PYTHONPATH didn't do anything for me).

@germanfr it's a huge project. Whatever package is using this as a dep, maybe you should talk to them about providing a pre-built alternative.

Scimmia commented on 2017-12-30 08:48

"That's not ok."? It's webkit, what the hell do you expect?

germanfr commented on 2017-12-30 08:30

It took me 7h to build this package as an update. That's not ok.

yan12125 commented on 2017-12-28 09:07

@Batou: Check out @zoidby's comment