Re: Next Chromium release will require unreleased LLVM
"alice" <[email protected]> Fri, 12 May 2023 09:20:05 +0200
| Newsgroups | dev.linux.lists.distributions |
|---|---|
| Message-ID | <CSK485O0FQVG.1CHVG3HMG8FP6@sumire> |
On Thu May 11, 2023 at 1:43 PM CEST, Alyssa Ross wrote: > On Thu, May 11, 2023 at 01:35:48PM +0200, Ryan Lahfa wrote: > > On Thu, May 11, 2023 at 06:16:03AM -0400, Neal Gompa wrote: > > > We only recently switched building Chromium from GCC to Clang. > > > Switching back might be an option too, depending on what the > > > compatibility looks like. > > > > I thought that Chromium was tightly coupled to Clang for compilation. > > Not quite: > https://chromium.googlesource.com/chromium/src/+/main/docs/clang.md#Using-gcc-on-Linux the issues with building chromium with gcc are twofold: - skia (part of the chromium build dep tree) is significantly worse built with gcc than clang, see e.g. the skia docs https://skia.org/docs/user/build/ #supported-and-preferred-compilers. i'd also say that similarly, g++ is much worse as a c++ compiler for the chromium tree- it uses far more memory per TU, etc. (i'd say that for most c++ projects, but most things are not big enough that you're going to notice) - the gcc configuration generally requires even more patches to build compared to not using it. as noted, it's not tested, so pretty much every release there can be a small bug or two in the same fashion as this specific case requiring intervention. (and this is distinct from libstdc++ vs custom_libcxx, to be exact) overall, i think this is a little overblown. it's quite known that latest chromium needs whatever latest llvm toolchain to build- perhaps it's a bit new that in this instance the llvm toolchain is not even released yet, but i think that was inevitable given that chromium's llvm policy is that they bump to latest master every 2-4 weeks (see https://chromium.googlesource.com/chromium/src/+/main/docs/toolchain_support.md) so, it was a matter of time until an M release required unsupported flags in latest released llvm. but for distros this is nothing new. for instance when you happen to do a new llvm upgrade, you can generally unset chrome_pgo_phase=0 (the vendored pgo profile shipped with clang tarball requires latest llvm, so you don't need to set this if the stars align, but then you have to set it again when chrome's is too new), arch linux for instance have to patch their clang15 (https://github.com/archlinux/svntogit-packages/commit/410325df892f54322a6abb68569db639128a045d) to build it at all with older llvm, M113 rolled some libraries to latest(git) so the system ones don't work anymore (common occurence really, every other release has this happen), chromium doesn't (yet) support libstdc++13 without a bunch of patches (mostly cstdint includes), ... so, a patch like reverting the CL for llvm17-only ld.lld flags as linked here is nothing out of the ordinary (i think something identical even happened before, but i don't remember anymore). i'd imagine everyone would do exactly that, just like we all always have, a small trivial patch :)