This strictly isn't a bug or an enhancement, although it could be. It's more a description of a hole I've fallen into several times and am wondering if there's a recommended/supported way to avoid doing so easily or maybe the build could be adjusted to avoid it. So here goes... Chromium is a big build, so I presume like many people, I use distcc (and ccache). My distcc nodes all have the same compiler commands configured, preferring the latest version(s). Chromium comes along and (like several packages) selects a version of LLVM that is not the latest as per the max slot 14 setting, where 15 is now widely available. It then invokes it [somehow, PATH?] without a version in the command line (x86_64-pc-linux-gnu-clang++)... that gets distributed via distcc which then uses v15 to perform the compilation... which is then cached. All is basically well until the link stage, where it fails because objects compiled with v14 are rejected by the v14 linker (this might be LTO getting into the mix too) So yes, the strictly speaking answer is build it without distcc/ccache before filing a bug, I know :) Sorry. But thinking out loud, in the case where a specific version of a toolset is selected, should/could it invoke that toolset with a version in it? Could/should `x86_64-pc-linux-gnu-clang++` be `x86_64-pc-linux-gnu-clang++-14` which on the face of it, makes the whole problem go away (maybe overly simplified)? I appreciate people's time here, pre-emptive thank you :)
It's not www-client/chromium specific, but rather a problem with how llvm.eclass overrides the used LLVM / clang version. Same thing happens with every package that uses that eclass to override the max LLVM slot, including www-client/firefox and mail-client/thunderbird. As you say, instead of overriding the LLVM version by editing PATH it should change CXX to something like x86_64-pc-linux-gnu-clang++-14 instead. CC'ing mgorny, since he's the author of llvm.eclass.
A workaround is to re-launch the build host distccd for every such package, with its PATH only containing the LLVM version matching the LLVM_MAX_SLOT defined in the package currently being built. Obviously, this requires careful attendance for emerge -u @world. Also, the title of this bug should be changed into something like: "llvm.eclass: incompatible with distcc".
Just for my own sanity, is it also the case that this from BDEPEND: lto? ( $(depend_clang_llvm_versions 13 14 15) ) Pulls in any version 13 to 15 of sys-devel/lld, which given LLVM_MAX_SLOT=14 and lld isn't slotted, can lead to a suitable version of lld not being found? I've masked v15 as a workaround to this... but I've also tried removing 15 from the above list which also appears to work.
I tried a build today and got x86_64-pc-linux-gnu-clang++: error: no such file or directory: '../../build/linux/unbundle/openh264_encoder_cfi_ignores.txt' due to the argument -fsanitize-ignorelist=../../build/linux/unbundle/openh264_encoder_cfi_ignores.txt which is not supported by distcc (or ccache).
The TL;DR here is that distcc is unsupported, though if there are ebuild changes that need to be made I'm willing to accept patches. In the longer term, the chromium ebuild is binpkg ready, I just need to do some portage work to make binhost builds work, hopefully that won't take too long!
One can go further with a distcc wrapper that removes the -fsanitize-ignorelist argument, only later to hit (-j128): ../../chrome/browser/ui/views/frame/browser_view.h:44:10: fatal error: 'components/enterprise/buildflags/buildflags.h' file not found
The previous issue is stochastic and probably due to a build system bug when a large number of jobs is used ; I was able to get the build to completion using distcc wrapping and a rebuild.
> due to the argument > -fsanitize-ignorelist=../../build/linux/unbundle openh264_encoder_cfi_ignores.txt > > which is not supported by distcc (or ccache). If there's some compiler command line argument that should be supported by distcc (even just by forcing a local fallback) then you should report it to the distcc upstream.
I'm planning to have a junior developer work on implementing this feature in distcc, along with others (SOURCE_DATE_EPOCH, -fstack-usage)...
(In reply to Dan Goodliffe from comment #0) > in the case > where a specific version of a toolset is selected, should/could it invoke > that toolset with a version in it? Could/should > `x86_64-pc-linux-gnu-clang++` be `x86_64-pc-linux-gnu-clang++-14` which on > the face of it, makes the whole problem go away (maybe overly simplified)? That is now exactly what happens. The logic was added as part of the overhaul in www-client/chromium-127.0.6533.72: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f9d4cf285d2218114c73c9a879d1ce3c6e67ca3e The crucial line is the call in pkg_setup() to llvm_fix_clang_version.
