The gn version depends on the channel and new gn versions aren't always
backward compatible. Therefore we should also include it in
upstream-info.json (I've scoped it under "deps" as we'll likely have to
add more like this in the future).
LLD: https://lld.llvm.org/
When you link a large program on a multicore machine, you can expect that LLD runs more than twice as fast as the GNU gold linker. Your mileage may vary, though.
Link-time optimization (LTO) is supported by default.
Some default settings have been tuned for the 21st century. For example, the stack is marked as non-executable by default to tighten security.
LTO & ThinLTO: https://clang.llvm.org/docs/ThinLTO.html
LTO (Link Time Optimization) achieves better runtime performance through whole-program analysis and cross-module optimization. However, monolithic LTO implements this by merging all input into a single module, which is not scalable in time or memory, and also prevents fast incremental compiles. ThinLTO is a new approach that is designed to scale like a non-LTO build, while retaining most of the performance achievement of full LTO.
PGO: https://llvm.org/docs/HowToBuildWithPGO.htmlhttps://blog.chromium.org/2020/08/chrome-just-got-faster-with-profile.html
Allows your compiler to better optimize code for how it actually runs. Users report that applying this to Clang and LLVM can decrease overall compile time by 20%.
Because PGO uses real usage scenarios that match the workflows of Chrome users around the world, the most common tasks get prioritized and made faster. Delivers up to 10% faster page loads.
CFI: https://clang.llvm.org/docs/ControlFlowIntegrity.htmlhttps://www.chromium.org/developers/testing/control-flow-integrity
Aborts the program upon detecting certain forms of undefined behavior that can potentially allow attackers to subvert the program’s control flow. These schemes have been optimized for performance, allowing developers to enable them in release builds.
By default, a program compiled with CFI will crash with SIGILL if it detects a CFI violation.
Additionally:
Use minizip instead of zlib. Chromium says zlib but actually uses minizip.
Remove old unused workarounds.
Make shell scripts POSIX compliant.
Update documentation URLs.
Prepare for using system libraries.
This should also fix VA-API for chromiumBeta (though that part needs
some cleanup). However, chromiumDev likely still fails due to the
absence of dirmd (not included in the tarball so far, we might have to
package and add it as a dependency).
Wanted to do this for a long time to collect important knowledge and
make it easier to pass maintainership.
Only time will tell if this'll be useful or become outdated instead.
Chromium 86.0.4240.75 builds fine without this patch. And since
WEBP_MAX_DIMENSION is the same in the system libwebp this patch should
not be required anymore (it was introduced in 06ec2a9f19, apparently to
fix the build).
By default GN produces a build with all of the debug assertions enabled (is_debug=true) and including full debug info (symbol_level=2). Setting symbol_level=1 will produce enough information for stack traces, but not line-by-line debugging. Setting symbol_level=0 will include no debug symbols at all. Either will speed up the build compared to full symbols.
This is done to avoid driver specific issues and restores the previous
behaviour. Like before video acceleration can be enabled without having
to rebuild Chromium.
This will additionally install the following files:
libEGL.so libGLESv2.so
libVkICD_mock_icd.so libvk_swiftshader.so libvulkan.so
libEGL.so and libGLESv2.so are required to fix our ANGLE support.
The rest should help with the Vulkan support (currently an experimental
feature that is disabled by default).
This is required for certain URIs that require launching external
programs (e.g. mailto:, magnet:, or irc:) or setting the default browser
via xdg-settings.
Fix#96897 and fix#92751.
This reverts commit 5da66561d1.
It seems the chromium build now unconditionally tries to enable ozone
(even though we disable it), causing the build to fail (as we only
provide xkbcommon when enabling Ozone):
```
configuring
ERROR at //build/config/linux/pkg_config.gni:103:17: Script returned non-zero exit code.
pkgresult = exec_script(pkg_config_script, args, "value")
^----------
Current dir: /build/chromium-87.0.4252.0/out/Release/
Command: python /build/chromium-87.0.4252.0/build/config/linux/pkg-config.py xkbcommon
Returned 1.
stderr:
Package xkbcommon was not found in the pkg-config search path.
Perhaps you should add the directory containing `xkbcommon.pc'
to the PKG_CONFIG_PATH environment variable
No package 'xkbcommon' found
Could not run pkg-config.
See //ui/events/ozone/layout/BUILD.gn:12:3: whence it was called.
pkg_config("xkbcommon") {
^------------------------
See //chrome/test/chromedriver/BUILD.gn:273:15: which caused the file to be included.
deps += [ "//ui/events/ozone/layout" ]
^-------------------------
builder for '/nix/store/2dqhrd2qzyms078wnvwv6ays53ppvgc2-chromium-unwrapped-87.0.4252.0.drv' failed with exit code 1
cannot build derivation '/nix/store/4iyhgzsmpx80v75hvk1jycwzanw4z5dn-chromium-dev-87.0.4252.0.drv': 1 dependencies couldn't be built
```
update.nix was a huuuuge hack, abusing checksum collisions, etc., and
was extremely difficult to read and maintain, especially because
values from update.nix were also used in the derivations themselves!
I've replaced this with an implementation in Python, which I chose for
readability. Rather than generating Nix, I chose to
generate JSON, since Python can do that in the standard library and
Nix can read it.
I also set update.py as an updateScript, so Chromium can now
automatically be updated!
Fixes: https://github.com/NixOS/nixpkgs/issues/89635
Note: The following might also need to be updated:
substituteStream(): WARNING: pattern '/usr/share/xcb' doesn't match anything in file 'ui/gfx/x/BUILD.gn'
I didn't look into this yet but IIRC M86 will finally have a flag for
Linux to enable VA-API. So we shouldn't need
enable-video-acceleration-on-linux.patch anymore.
But we likely need to update enable-vdpau-support-for-nvidia.patch
when/before M86 hits the stable channel if we want to keep VDPAU
support.
Ok, so I was about to update the patch (didn't apply anymore) when I
also started looking at it's usage and realized that
NIX_CHROMIUM_PLUGIN_PATH_ (and other substrings) only appears in the
patch itself (i.e. it seemed like we don't need this patch anymore).
Turns out that we have this patch since 2014 (1b84fbf0ca) and it was
only ever used for NIX_CHROMIUM_PLUGIN_PATH_WIDEVINE (and from the log
it isn't clear if/when or how well that worked). But in 2019 that last
usage got removed (545d58a1ef) so we should be able to safely drop this
patch now :) \o/
(I just wanted to note that as it seemed somewhat of a funny story :D
But there is of course nothing wrong with it.)
Git history (git log --oneline -S NIX_CHROMIUM_PLUGIN_PATH_):
7205bd64a3 ungoogled-chromium: init at 81.0.4044.92-2
545d58a1ef chromium: fix widevine
cd3283f921 chromium: 67.0.3396.99 -> 68.0.3440.75
72d7b5ddb1 chromium: fix nix_plugin_paths for 68+
7a3a16dd80 chromium: Remove plugin paths patch for version 50
79d18eb604 chromium: Update dev channel to v52.0.2743.10
c7a3645e7b chromium: Remove stuff for versions <= v51
8b97ca270e chromium: Update all channels to latest versions
b9093f1c64 chromium: Updates, fixes#11492471cdd15e2 chromium: Update beta and dev channels.
5c6aa391fc chromium: Cleanup old patch and update stable
af54ddf8b6 chromium: Drop plugin_paths patch for old versions.
6a8afa4bb3 chromium: Fix plugin_paths patch for version 44.
0aad4b7ee4 chromium: Update all channels to latest versions.
1b84fbf0ca chromium: Allow env vars for passing plugin paths.
This is more robust than depending on the channel, though the version
should only matter if the configuration phase fails.
This also switches to the intended version for `chromium` which should
be higher since M85 is in the stable channel.
Thanks `@volth` for pointing this out.
