This most notably fixes cross _evaluation_ of chromium which previously
would fail because makeWrapper relies on runtimeShell which is not
available in the HostTarget package set.
I tested that the native chromium build still works, but haven't tried
cross compiling it yet. There very well may be additional errors, but at
least they will be build errors, not hard to understand evaluation
errors.
This executable is required to fix a startup error.
TODO: Refactor the Nix expressions to allow chromiumVersionAtLeast, etc.
"everywhere" and investigate the VM test failure.
The final linking still fails though, even with llvm-git.
We might have to diable use_thin_lto for now:
ld.lld: error: undefined symbol: snappy::Compress(char const*, unsigned long, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*)
>>> referenced by compression_module.cc
>>> thinlto-cache/Thin-ed5ed5.tmp.o:(reporting::CompressionModule::CompressRecord(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, base::OnceCallback<void (std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, absl::optional<reporting::CompressionInformation>)>) const)
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
See https://bugs.chromium.org/p/chromium/issues/detail?id=1215229.
Before this the build failed with this error:
[101/47617] ACTION //build/util:chromium_git_revision(//build/toolchain/linux/unbundle:default)oaded_data.pbchain/linux/unbundle:default)
FAILED: gen/build/util/chromium_git_revision.h
python3 ../../build/util/lastchange.py --header gen/build/util/chromium_git_revision.h --revision-id-only --revision-id-prefix @ -m\ CHROMIUM_GIT_REVISION
ERROR:root:Failed to get git top directory from '/build/chromium-93.0.4542.2/build/util': Git command 'git git rev-parse --show-toplevel' in /build/chromium-93.0.4542.2/build/util failed: [Errno 2] No such file or directory: 'git'
This executable is required to fix a startup error:
[990:990:0609/092114.482805:FATAL:double_fork_and_exec.cc(131)] execv /nix/store/k02xhxzn6sn2cihaal68wwsyk8cg9pkg-chromium-unwrapped-93.0.4535.3/libexec/chromium/crashpad_handler: No such file or directory (2)
Unfortunately Chromium M93 still segfaults in the VM test:
machine # [0610/100626.225850:ERROR:process_memory_range.cc(75)] read out of range
machine # [0610/100626.227312:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2)
machine # [0610/100626.240410:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2)
machine # [ 19.810981] systemd-coredump[1015]: Process 987 (chromium) of user 1000 dumped core.
https://chromereleases.googleblog.com/2021/06/stable-channel-update-for-desktop.html
This update includes 14 security fixes. Google is aware that an exploit
for CVE-2021-30551 exists in the wild.
CVEs:
CVE-2021-30544 CVE-2021-30545 CVE-2021-30546 CVE-2021-30547
CVE-2021-30548 CVE-2021-30549 CVE-2021-30550 CVE-2021-30551
CVE-2021-30552 CVE-2021-30553
This will begin the process of breaking up the `useLLVM` monolith. That
is good in general, but I hope will be good for NetBSD and Darwin in
particular.
Co-authored-by: sterni <sternenseemann@systemli.org>
LLVM 12 is required but the build still fails due to other changes that
where introduced in the meantime (and Chromium 90.0.4430.51 introduced
another LLVM failure).
The builds currently fail with (should work with LLVM 12 [0]):
../../base/check.h:88:3: error: 'nomerge' attribute cannot be applied to a declaration
NOMERGE ~CheckError();
^ ~
../../base/compiler_specific.h:344:19: note: expanded from macro 'NOMERGE'
#define NOMERGE [[clang::nomerge]]
^
1 error generated.
[0]: fb0f728805
Chromium is still compiled with use_vaapi=true but since M89 the
--enable-accelerated-video-decode was replaced with
--enable-features=VaapiVideoDecoder.
Instead of updating our wrapper it seems like a better idea to drop
enableVaapi entirely and let users use commandLineArgs or
chrome://flags/ to enable hardware accelerated video decoding.
And close#78450 because I'm maintaining Chromium for approximately one
year now and it looks like I can keep maintaining it (at least as long
as I have enough time for it). I'm also working on the documentation,
automation, and cleanups so finding a new maintainer in the future
should hopefully be easier.
During d6d4228b39 I failed to notice that the current chromiumDev
version is older than the first one that contained the commit to fix the
dependency on opus in webcodecs.
This should hopefully fix build of chromiumDev (if there are no
additional issues).
Unfortunately this requires a crazy hack to support building with
Google's proprietary Widevine DRM technology as that requires fetching
the Google Chrome sources (see also 86ff1e45ce).
The hack is required because ungoogled-chromium doesn't always use tags
that correspond to a Google Chrome release.
The build was failing with:
In file included from ../../third_party/blink/renderer/modules/webcodecs/audio_encoder.cc:7:
In file included from ../../media/audio/audio_opus_encoder.h:16:
gen/shim_headers/opus_shim/third_party/opus/src/include/opus.h:5:10: error: 'opus.h' file not found with <angled> include; use "quotes" instead
#include <opus.h>
^~~~~~~~
"opus.h"
[...]
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
[42272/44233] CXX obj/third_party/blink/renderer/modules/webcodecs/webcodecs/decoder_template.oo[K
Note: This also fixes the ungoogled-chromium channel name in versionRange.
I forgot that string comparison isn't enough because e.g.:
>>> "89.0.4389.9" < "89.0.4389.23"
False
distutils.version.LooseVersion is undocumented but it works and is
already available so why not use it:
>>> LooseVersion("89.0.4389.9") < LooseVersion("89.0.4389.23")
True
The "channel" variable shouldn't be part of the final derivation. This
also makes it possible to avoid unnecessary rebuilds for identical
channels (e.g. major updates are tested via the "beta" channel first and
usually neither the source-code archive nor the dependencies change when
the update makes it into the "stable" channel - this means we could
better use chromiumBeta to test major updates in advance).
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
This also adds a dedicated channel for ungoogled-chromium that enables
us to update ungoogled-chromium independently of chromium.
TODO: Automate ungoogled-chromium updates via update.py (currently it
needs to be updated manually).
Note: Unfortunately this changes the ungoogled-chromium derivation
because common.nix passes the channel as an argument to
stdenv.mkDerivation (this makes it more difficult to verify this commit
but the result should remain the same).
I used nix-instantiate to verify that the derivations for chromium and
ungoogled-chromium remain unchanged (only the meta attributes change
slightly as I added myself as ungoogled-chromium to receive
notifications for PRs/issues).
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
