| Summary: | www-client/chromium does not respect LLVM_MAX_SLOT when clang is a system compiler | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Chris Pritchard <chris> |
| Component: | Current packages | Assignee: | Chromium Project <chromium> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | chris, kangie |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 926505 | ||
| Attachments: |
build.log
updated ebuild patch between ebuilds |
||
Oddly, I modified the ebuild to output ${AR} --version at the start and end of chromium_configure()
* LLVM (http://llvm.org/): LLVM version 18.1.0+libcxx Optimized build.
[...]
* LLVM (http://llvm.org/): LLVM version 17.0.6+libcxx Optimized build.
So somewhere in chromium_configure() somehow, the value of ${AR} is changing, and I can't work out where.
After updating LLVM_MAX_SLOT to 18 within the ebuild, the build progresses (I haven't finished building yet), but will confirm tomorrow whether the build completes using clang-18. It appears that when clang is the default compiler, clang is not set as the compiler within the ebuild. However, some other tools are set depending on use flag (in my case, ar is set to llvm-ar because I had the lto use flag enabled). When the tools are set within the ebuild, they are set to the slotted version as expected, but if they are not set within the ebuild then the default version is used, which can exceed the version that would be called LLVM_MAX_SLOT is respected. I would imagine a fix would be to check to see if we're using clang as a system compiler, and if we are, manually set the relevant variables such that LLVM_MAX_SLOT is respected (I think the ones set by tc-export, so AR, CC, CXX, NM)? Created attachment 887808 [details]
updated ebuild
Created attachment 887809 [details, diff]
patch between ebuilds
Firstly, I can confirm that chromium builds and runs fine with LLVM_MAX_SLOT=18, although obviously no in depth testing has been performed. Secondly, updating the ebuild as per the attached ebuild and patch seems to do the trick in forcing clang to be between min and max slotted version, I'm unsure if there's a better way > I can confirm that chromium builds and runs fine with LLVM_MAX_SLOT=18
That's not too surprising - the bundled toolchain is at clang 19 for 123!
Thanks for the patch. I'll look at applying it for this week's bump.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4d934c6292b3de7a0cfac7143361531a149b93af commit 4d934c6292b3de7a0cfac7143361531a149b93af Author: Matt Jolly <kangie@gentoo.org> AuthorDate: 2024-03-20 04:22:43 +0000 Commit: Matt Jolly <kangie@gentoo.org> CommitDate: 2024-03-20 10:30:44 +0000 www-client/chromium: add 123.0.6312.58 Attempt to better handle users with clang as their default compiler (previously we could get out of sync). Back to depending on virtual/rust thanks to the recent addition of the `profiler` USE. Bumped enabled LLVM slots from 16 to 17 to 17 to 19. Bug: https://bugs.gentoo.org/927154 Bug: https://bugs.gentoo.org/927312 Signed-off-by: Matt Jolly <kangie@gentoo.org> www-client/chromium/Manifest | 1 + www-client/chromium/chromium-123.0.6312.58.ebuild | 1388 +++++++++++++++++++++ 2 files changed, 1389 insertions(+) This _should_ be fixed now. Would you mind letting me know how you go and closing the ticket if all seems good? |
Created attachment 887778 [details] build.log When using clang-18, chromium fails to build with the following error: llvm-ar: error: obj/base/allocator/partition_allocator/src/partition_alloc/liballocator_base.a: 'allocator_base/stringprintf.o': Unknown attribute kind (91) (Producer: 'LLVM18.1.0+libcxx' Reader: 'LLVM 17.0.6+libcxx') It appears that the build is trying to use an old version of llvm-ar, despite the system version being 18.1.0+libcxx