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
