The build argument `use_system_libwayland_server` was set to `false`
since M107 [0]. This will cause `libwayland` to be built which does in
turn pull in `libffi` ("//build/config/linux/libffi") [1].
Alternatively, we should be able to fix the libffi dependency by setting
`use_system_libffi = true` (recently added, see [2]) and adding `libffi`
to the build inputs.
[0]: b9cd6d6767
[1]: https://source.chromium.org/chromium/chromium/src/+/refs/tags/107.0.5304.62:third_party/wayland/BUILD.gn
[2]: cf3ee09f08
Setting `clang_base_path` [0] does skip [1] a clang version check [2]
that would fail in our case:
```
configuring
ERROR at //build/config/compiler/BUILD.gn:1314:22: Script returned non-zero exit code.
clang_revision = exec_script("//tools/clang/scripts/update.py",
^----------
Current dir: /tmp/nix-build-chromium-unwrapped-107.0.5304.29.drv-0/chromium-107.0.5304.29/out/Release/
Command: python3 /tmp/nix-build-chromium-unwrapped-107.0.5304.29.drv-0/chromium-107.0.5304.29/tools/clang/scripts/update.py --print-revision --verify-version=16.0.0
Returned 1 and printed out:
The expected clang version is llvmorg-16-init-4609-g025a5b22-2 but the actual version is
Did you run "gclient sync"?
See //build/config/BUILDCONFIG.gn:329:3: which caused the file to be included.
"//build/config/compiler:afdo",
^-----------------------------
error: builder for '/nix/store/02riyhzvrgn2vaab29d3gipxzkx6nb44-chromium-unwrapped-107.0.5304.29.drv' failed with exit code 1
```
I also chose to disable the Qt support for now. The Qt support is
enabled by default on Linux [3] but we need to add the required
dependencies first to fix the build (and my current priority is to get a
basic build working for the security critical stable channel update):
```
configuring
ERROR at //build/config/linux/pkg_config.gni:104:17: Script returned non-zero exit code.
pkgresult = exec_script(pkg_config_script, args, "value")
^----------
Current dir: /tmp/nix-build-chromium-unwrapped-107.0.5304.62.drv-0/chromium-107.0.5304.62/out/Release/
Command: python3 /tmp/nix-build-chromium-unwrapped-107.0.5304.62.drv-0/chromium-107.0.5304.62/build/config/linux/pkg-config.py Qt5Core Qt5Widgets
Returned 1.
stderr:
Package Qt5Core was not found in the pkg-config search path.
Perhaps you should add the directory containing `Qt5Core.pc'
to the PKG_CONFIG_PATH environment variable
No package 'Qt5Core' found
Package Qt5Widgets was not found in the pkg-config search path.
Perhaps you should add the directory containing `Qt5Widgets.pc'
to the PKG_CONFIG_PATH environment variable
No package 'Qt5Widgets' found
Could not run pkg-config.
See //ui/qt/BUILD.gn:13:1: whence it was called.
pkg_config("qt5_config") {
^-------------------------
See //ui/linux/BUILD.gn:54:15: which caused the file to be included.
deps += [ "//ui/qt" ]
^--------
error: builder for '/nix/store/3zzddkh74cnhvq6nql32y9pnbvzf2jv9-chromium-unwrapped-107.0.5304.62.drv' failed with exit code 1
```
[0]: https://source.chromium.org/chromium/chromium/src/+/refs/tags/107.0.5304.62:docs/clang.md
[1]: https://source.chromium.org/chromium/chromium/src/+/refs/tags/107.0.5304.62:build/config/compiler/BUILD.gn;l=1306
[2]: https://source.chromium.org/chromium/chromium/src/+/refs/tags/107.0.5304.62:tools/clang/scripts/update.py;l=358
[3]: https://source.chromium.org/chromium/chromium/src/+/refs/tags/107.0.5304.62:ui/qt/qt.gni;l=8
Passing `-l$NIX_BUILD_CORES` improperly limits the overall system load.
For a build machine which is configured to run `$B` builds where each
build gets `total cores / B` cores (`$C`), passing `-l $C` to make will
improperly limit the load to `$C` instead of `$B * $C`.
This effect becomes quite pronounced on machines with 80 cores, with
40 simultaneous builds and a cores limit of 2. On a machine with this
configuration, Nix will run 40 builds and make will limit the overall
system load to approximately 2. A build machine with this many cores
can happily run with a load approaching 80.
A non-solution is to oversubscribe the machine, by picking a larger
`$C`. However, there is no way to divide the number of cores in a way
which fairly subdivides the available cores when `$B` is greater than
1.
There has been exploration of passing a jobserver in to the sandbox,
or sharing a jobserver between all the builds. This is one option, but
relatively complicated and only supports make. Lots of other software
uses its own implementation of `-j` and doesn't support either `-l` or
the Make jobserver.
For the case of an interactive user machine, the user should limit
overall system load using `$B`, `$C`, and optionally systemd's
cpu/network/io limiting features.
Making this change should significantly improve the utilization of our
build farm, and improve the throughput of Hydra.
