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 :)