1 Topic by aloniv (edited by aloniv 2022-08-31 14:52:14)

  • aloniv
  • Hyper Expert
  • Offline
  • Registered: 2018-08-16
  • Posts: 153

Topic: WebKitGTK compilation from PKGBUILD requires manual intervention

When I tried compiling WebKitGTK from Hyperbola's PKGBUILD using only one process (replacing make with "make -j1") and with a sufficiently large swap file (6GB plus 2GB memory) the process terminates at around 97% with the error: 

No rule to make target 'JavaScriptCore-4.0.gir'

See this bug report:
https://bugs.webkit.org/show_bug.cgi?id=195251
A simple dirty hack is to pause the compilation after it is done with the JavaScriptCore directory at around 39% using Ctrl+Z, go to the JavaScriptCore directory (by running "cd src/build/Source/JavaScriptCore/"), run make and then resume the building of the PKGBUILD using the "fg" command (it will no longer display the percentages but the compilation will finish successfully if you pause and resume occasionally to prevent shutdown due to overheating).

PS - I also tried running the PKGBUILD with "make -j2" and with "make -j1 JavaScriptCore-4-gir -C build" before "make -j1 -C build" but both of those also terminated with compilation errors.

2 Reply by throgh

  • throgh
  • throgh
  • Package Development and Community Coordinator
  • Offline
  • From: Planet Earth
  • Registered: 2017-12-28
  • Posts: 2,924

Re: WebKitGTK compilation from PKGBUILD requires manual intervention

Perhaps this modification is helpful:

# Contributor (Arch): Eric Bélanger <eric@archlinux.org>
# Maintainer: André Silva <emulatorman@hyperbola.info>
# Maintainer: Márcio Silva <coadde@hyperbola.info>
# Contributor: Luke R. <g4jc@hyperbola.info>

pkgname=webkitgtk
_pkgname=webkit2gtk
pkgver=2.32.1
pkgrel=2
_debver=$pkgver
_debrel=2
pkgdesc='Web content engine for GTK'
url="https://$pkgname.org"
arch=(i686 x86_64)
# WebCore uses LGPL-2.1, LGPL-2 or Simplified-BSD
# JavaScriptCore uses LGPL-2
# WebDriver, WebKit and WebInspectorUI uses Simplified-BSD
# builtin angle library uses Clear-BSD
# builtin xdgmime library uses LGPL-2 or AFL-2.0
# other pieces of code uses Unicode, Modified-BSD, Simplified-BSD and Expat
# unused tools (like skeletons and m4sugar) uses GPL-3 and GPL-2
license=(LGPL-2.1)
# this package contains builtin libraries, like:
# angle and xdgmime, it require patch to separate it
# disabled builtin libraries, are: capstone, gtest and libwebrtc
depends=(enchant gperf gst-plugins-bad gst-plugins-base gtk harfbuzz-icu hyphen libmanette libxslt libxt mesa-libgl sqlite woff2)
optdepends=('gobject-introspection: gir bindings')
makedepends=(cmake gobject-introspection python quilt ruby ninja)
provides=($_pkgname)
conflicts=($_pkgname)
replaces=($_pkgname)
source=($url/releases/webkitgtk-$pkgver.tar.xz{,.asc}
        https://deb.debian.org/debian/pool/main/w/$_pkgname/${_pkgname}_$_debver-$_debrel.debian.tar.xz)
sha512sums=('ff49522c585d3c5c9b88c4176673aebfdf7f2a127d7bc4007008a66c493476ae6551189865e4f0f330a7b332a438b6c951bf1a4c21cd0acf69b7051903d24843'
            'SKIP'
            '5dbe43329e967517674837b751eeedfbee70aebaf73525d72f8a87190117a64318fc6978f06df1c288c1370781d60e05476a533a0c1d5a469f92a7c320dee96c')
validpgpkeys=('D7FCF61CF9A2DEAB31D81BD3F3D322D0EC4582C3'  # Carlos Garcia Campos <cgarcia@igalia.com>
              '5AA3BC334FD7E3369E7C77B291C559DBE4C9123B') # Adrián Pérez de Castro <aperez@igalia.com>

prepare() {
  cd $pkgname-$pkgver
  if [[ ${pkgver%.*} = ${_debver%.*} ]]; then
    # Debian patches
    export QUILT_PATCHES=debian/patches
    export QUILT_REFRESH_ARGS='-p ab --no-timestamps --no-index'
    export QUILT_DIFF_ARGS='--no-timestamps'

    mv "$srcdir"/debian .

    quilt push -av
  fi
}

build() {
  CFLAGS+=' -g1'
  CXXFLAGS+=' -g1'

  cmake -S $pkgname-$pkgver -B build -G Ninja \
    -D CMAKE_BUILD_TYPE=Release \
    -D CMAKE_INSTALL_PREFIX=/usr \
    -D CMAKE_INSTALL_LIBDIR=lib \
    -D CMAKE_INSTALL_LIBEXECDIR=libexec \
    -D CMAKE_SKIP_RPATH=ON \
    -D DEVELOPER_MODE=OFF \
    -D ENABLE_API_TESTS=OFF \
    -D ENABLE_BUBBLEWRAP_SANDBOX=OFF \
    -D ENABLE_GAMEPAD=ON \
    -D ENABLE_GLES2=OFF \
    -D ENABLE_GTKDOC=OFF \
    -D ENABLE_MINIBROWSER=ON \
    -D ENABLE_SPELLCHECK=ON \
    -D PORT=GTK \
    -D USE_LIBNOTIFY=OFF \
    -D USE_LIBSECRET=OFF \
    -D USE_OPENGL_OR_ES=ON \
    -D USE_SYSTEMD=OFF \
    -D USE_WPE_RENDERER=OFF

  cmake --build build
}

package() {
  DESTDIR="$pkgdir" cmake --install build
  install -Dm644 $pkgname-$pkgver/Source/WebCore/LICENSE-LGPL-2.1 -t $pkgdir/usr/share/licenses/$pkgname
}

# vim:set sw=2 et:
Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

3 Reply by aloniv

  • aloniv
  • Hyper Expert
  • Offline
  • Registered: 2018-08-16
  • Posts: 153

Re: WebKitGTK compilation from PKGBUILD requires manual intervention

Thanks - is it possible to compile without overheating the computer?

I tried using auto-cpufreq (with --monitor parameter) with the lowest CPU frequency (1000 MHz) but the computer still reached close to the maximum temperature.

4 Reply by throgh

  • throgh
  • throgh
  • Package Development and Community Coordinator
  • Offline
  • From: Planet Earth
  • Registered: 2017-12-28
  • Posts: 2,924

Re: WebKitGTK compilation from PKGBUILD requires manual intervention

That's a good question. Some builds are trying to allocate most all possible resources of the system for fast results. I have done the run under a 32bit-only system yesterday. Perhaps you can tryout with modifications on the scaling governors: https://wiki.archlinux.org/title/CPU_fr … _governors

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

5 Reply by aloniv (edited by aloniv 2022-09-01 14:50:47)

  • aloniv
  • Hyper Expert
  • Offline
  • Registered: 2018-08-16
  • Posts: 153

Re: WebKitGTK compilation from PKGBUILD requires manual intervention

I used these settings in /etc/auto-cpufreq.conf in charger section.

scaling_max_freq = 1000000
governor = powersave

Should I change the settings?

These are the governors available on my computer:

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance schedutil

PS - I should have run auto-cpufreq with --live and not --monitor.

6 Reply by throgh

  • throgh
  • throgh
  • Package Development and Community Coordinator
  • Offline
  • From: Planet Earth
  • Registered: 2017-12-28
  • Posts: 2,924

Re: WebKitGTK compilation from PKGBUILD requires manual intervention

Depends on your system, you can also try "userspace". Nevertheless the build-process will always try to enumerate what is available.

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

7 Reply by zapper

  • zapper
  • zapper
  • Hyper Cyber
  • Offline
  • Registered: 2017-10-18
  • Posts: 1,075

Re: WebKitGTK compilation from PKGBUILD requires manual intervention

aloniv wrote:

I used these settings in /etc/auto-cpufreq.conf in charger section.

scaling_max_freq = 1000000
governor = powersave

Should I change the settings?

These are the governors available on my computer:

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance schedutil

PS - I should have run auto-cpufreq with --live and not --monitor.

I am going to guess you have something older than an x200, but on the off chance you aren't, curious if yours is a dual core or quad core.

However, If its a single core and is 32 bit... then yikes...

you will have a lot of issues probably.

I could barely run firefox prior to version 52ESR being killed off by mozilla a while back...

The device I speak of though was a 10.1 netbook acer aspire something?

It had an hdd was 32 bit and had 1GB of ram.

If I tried to use just make, probably on that, it would have overheated to death point probably... xD

But yeah, if you suspend it occasionally or have it in a very cold room, it still probably will have issues even if yours is 4x faster than the device I mentioned or can handle 4x more heat.

That being said, if you do both of the above things, cold room + suspending every now and then, you should be fine.

Also, some stuff built with make can be continued, even if it fails in the middle, as long as:

YOU DON'T DELETE THE FILE AND RESUME AFTER POWER GOES OFF!*

I put this in caps, because, this sometimes helps enormously...

as for the asterisk, after OFF!

There are certain ways if it crashes, that stuff doesn't get saved...

sad

Hope you can figure this out!

Btw, as an ironic mention. my computers have had issues of late, due to permission errors, had to reinstall, etc...

So thats why havent been on lol.

HyperbolaBSD: The Future of Secure Libre Lightweight Operating Systems!

8 Reply by aloniv (edited by aloniv 2022-09-02 07:16:38)

  • aloniv
  • Hyper Expert
  • Offline
  • Registered: 2018-08-16
  • Posts: 153

Re: WebKitGTK compilation from PKGBUILD requires manual intervention

I'm using a dual core T60 with 2GB of RAM and the 64 bit version of Hyperbola (so yes it is older than the X200).

9 Reply by throgh

  • throgh
  • throgh
  • Package Development and Community Coordinator
  • Offline
  • From: Planet Earth
  • Registered: 2017-12-28
  • Posts: 2,924

Re: WebKitGTK compilation from PKGBUILD requires manual intervention

And I am building all the 32bit-packages for testing on a ThinkPad X60 Tablet. The little notebook has to do many things, but a fresh bit of thermal paste is doing wonders. No problems ahead and the system is running solid. smile

Please don't use "the computer is (too) old"-argument. Yes, older systems will take more time with compilation, but under generic circumstances you will for sure reach the goal and to argument with "waste of time", "endless waiting for process to finish" or "optimize your workload" - the list is for sure endless - people just find some reasoning for their own search but making it as named "common sense". Well? Depends: If any individual is happy with more fast computing, no problem. But please: Don't forget about the older systems and their reasoning not to be thrown away as defined "trash". That's a desastrous outcome for climate and more!

Therefore don't call those systems "(too) old" or "(too) slow". It just depends on what I'm ready to wait for and on the concurrent use-case. Yes, SSD is fast and more RAM is also nice. But as said: More dependencies, more time to invest and more time to research if something is not functional. Therefore the point about "closing threads". We care about a system being lightweight for a reasoning as we don't want to waste resources. It is even sometimes not fine that some packages afford a more capable implementation of the OpenGL-version, just as example. And personally I don't think it is helpful to go with "the faster, the better" as result. This brought us exactly to the point where we are now! Any X200 is not too old, any X60 or T60-generation is not too old. It is just referring the personal situation and what I await personal. This can be nevertheless sufficient for others: As long as a system is in usage, it is not "dead", not "unused" and not "old". We had systems running on those computers without any further problems or solved the ones back the time. Just to compare them is not fair enough with systems now: They are older, for sure. And then what? For reasoning we should care about the systems instead of looking forward for any solution in the future as we have to deal with the problems now without waiting for whatever or someone is doing it. We can do it now and that's with bringing those systems back with usage. Just because we start now with 16 GB of RAM for example, does not mean we have the time to waste that more and more, write more and more bloated software and frameworks. Because? Well, why not? That's a circle and it is a false balanced one: Having those systems trashed at a point is really bad for sure and we cannot mark them as being "not useful" same as the systems with Atom-processors for example. Caring means to start now and make the systems affordable to run software also today. Therefore 32bit is to be cared about and just because some ignorance is coming back does not make that especially logic (ignorance for dropping support for 32bit / x86).

Besides that's another reasoning: GNU/Linux is leaving those fields where you could argument that it make former generations "good to go", inacceptable.

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!