Next Chromium release will require unreleased LLVM

Next Chromium release will require unreleased LLVM

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

The Chromium 114 beta uses features from LLVM 17, but will release
before LLVM 17 does.  Currently, it looks like it wouldn't be too hard
to patch to make it compatible with LLVM 16, but in general, we don't
have any guarantee that Chromium will build with a released LLVM.

So, how do you intend to handle this situation in your distribution?
It seems like it will be a problem we'll all share, especially if it
gets worse in future.

Nixpkgs discussion:
https://github.com/NixOS/nixpkgs/issues/213862#issuecomment-1542887001

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Next Chromium release will require unreleased LLVM

[Neal Gompa]

On Thu, May 11, 2023 at 5:27 AM Alyssa Ross <hi@alyssa.is> wrote:
>
> The Chromium 114 beta uses features from LLVM 17, but will release
> before LLVM 17 does.  Currently, it looks like it wouldn't be too hard
> to patch to make it compatible with LLVM 16, but in general, we don't
> have any guarantee that Chromium will build with a released LLVM.
>
> So, how do you intend to handle this situation in your distribution?
> It seems like it will be a problem we'll all share, especially if it
> gets worse in future.
>
> Nixpkgs discussion:
> https://github.com/NixOS/nixpkgs/issues/213862#issuecomment-1542887001

I suspect we in Fedora will do the same thing and revert/modify things
to work with LLVM/Clang 16. It is, however, not out of the question
for us to ship multiple versions of LLVM+Clang in Fedora, so once LLVM
17 is shipped in Fedora, we will probably switch Chromium to that.

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'm personally not a fan of the Clang/LLVM toolchain after having
worked on building distributions entirely using it before. But alas,
I'm in the minority. :/




--
Neal Gompa (FAS: ngompa)

Re: Next Chromium release will require unreleased LLVM

[Ryan Lahfa]

On Thu, May 11, 2023 at 06:16:03AM -0400, Neal Gompa wrote:
> On Thu, May 11, 2023 at 5:27 AM Alyssa Ross <hi@alyssa.is> wrote:
> >
> > The Chromium 114 beta uses features from LLVM 17, but will release
> > before LLVM 17 does.  Currently, it looks like it wouldn't be too hard
> > to patch to make it compatible with LLVM 16, but in general, we don't
> > have any guarantee that Chromium will build with a released LLVM.
> >
> > So, how do you intend to handle this situation in your distribution?
> > It seems like it will be a problem we'll all share, especially if it
> > gets worse in future.
> >
> > Nixpkgs discussion:
> > https://github.com/NixOS/nixpkgs/issues/213862#issuecomment-1542887001
> 
> I suspect we in Fedora will do the same thing and revert/modify things
> to work with LLVM/Clang 16. It is, however, not out of the question
> for us to ship multiple versions of LLVM+Clang in Fedora, so once LLVM
> 17 is shipped in Fedora, we will probably switch Chromium to that.

We already do the same in nixpkgs (from LLV5 to LLVM16 at the moment,
but hopefully, we start dropping the oldest ones).

> 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.

> I'm personally not a fan of the Clang/LLVM toolchain after having
> worked on building distributions entirely using it before. But alas,
> I'm in the minority. :/

Curious about your pain points, but, probably off-topic. :)

Kind regards,
-- 
Ryan Lahfa

Re: Next Chromium release will require unreleased LLVM

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Next Chromium release will require unreleased LLVM

[alice]

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

Re: Next Chromium release will require unreleased LLVM

[Ryan Lahfa]

On Fri, May 12, 2023 at 09:20:05AM +0200, alice wrote:
> 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
> 
> 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 :)

I was just wondering if there would be a day where it would be hard to
revert the relevant patches from LLVM "git" for building Chromium, which
would require a change in our strategy.

Obviously, a trivial patch is not a big deal.

Kind regards,
-- 
Ryan Lahfa