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.
As discussed in #101429 firefox 82 started crashing when used with
wayland. A brief investigation showed that this appears to be rooted
within the LTO support that was recently added to the package. For the
time being, until someone figures out where the crashes are coming from,
we can just disable LTO.
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 ensures that we aren't applying any of the experiemental pipewire
patches when the dependencies aren't enabled. As of now pipewire only
works with wayland and webrtc. If either of them are not activated we
can't build with pipewireSupport and we should not.
