Hello, I hit this morning this issue while updating my system: # SYMLINK /var/tmp/portage/x11-drivers/nvidia-drivers-550.78/work/kernel/nvidia/nv-kernel.o ln -sf /var/tmp/portage/x11-drivers/nvidia-drivers-550.78/work/kernel/nvidia/nv-kernel.o_binary /var/tmp/portage/x11-drivers/nvidia-drivers-550.78/work/kernel/nvidia/nv-kernel.o ccache: error: Could not find compiler "x86_64-pc-linux-gnu-gcc-12" in PATH The C compiler '/usr/lib/ccache/bin/x86_64-pc-linux-gnu-gcc-12' does not appear to be able to create object files. Please make sure you have your Linux distribution's libc development package installed and that '/usr/lib/ccache/bin/x86_64-pc-linux-gnu-gcc-12' is a valid C compiler name. *** Failed CC sanity check. Bailing out! *** make[3]: *** [/var/tmp/portage/x11-drivers/nvidia-drivers-550.78/work/kernel/Kbuild:275: cc_sanity_check] Error 1 make[2]: *** [/usr/src/linux-6.6.21-gentoo/Makefile:1913: /var/tmp/portage/x11-drivers/nvidia-drivers-550.78/work/kernel] Error 2 make[1]: *** [Makefile:234: __sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-6.6.21-gentoo' make: *** [Makefile:85: modules] Error 2 * ERROR: x11-drivers/nvidia-drivers-550.78::gentoo failed (compile phase): I was surprised to still have /usr/lib/ccache/bin/x86_64-pc-linux-gnu-gcc-12 as gcc-12 version was depcleaned some days ago. I then simply tried to re-emerge ccache... and it worked fine. I then realized that, at the top of the nvidia-drivers build.log, I was having this warning (from linux-mod.eclass): * Warning: kernel 6.6.21-gentoo is built with gcc-12 but * '/usr/lib/ccache/bin/x86_64-pc-linux-gnu-gcc-12' is not gcc * This *could* result in build issues or other incompatibilities. * It is recommended to either `make clean` and rebuild the kernel * with the current toolchain (for distribution kernels, re-installing * will do the same), or set the KERNEL_CC variable to point to the * same compiler. Note that when it is available, auto-selection is * attempted making the latter rarely needed. But I still wonder about why "eselect compiler-shadow update ccache" is not executed at gcc depcleaning. I think that could solve most of these issues without users starting to play with KERNEL_CC variable or similar Thanks for your help
Also affects clang, which can also be selected as a kernel compiler. linux-mod-r1 uses "type -P" to find these, dead symlinks would be ignored by that but these are never dead given they point to /usr/bin/ccache. Wouldn't be impossible to do messy workarounds for validity but having compiler-shadow be updated sounds cleaner and it could solve other problems (imagine this is worse if the "newer" compiler is depcleaned).
(In reply to Ionen Wolkens from comment #1) > Wouldn't be impossible to do messy workarounds for validity Well, not that messy given it already does a check + warn because of it, but it'd still need to assume it's broken and then try the next compiler in PATH which in itself gets messy.
(In reply to Ionen Wolkens from comment #1) > Also affects clang, which can also be selected as a kernel compiler. Or not, I see it's there in postrm already -- assumed that if gcc doesn't do it then clang probably didn't either.
(In reply to Ionen Wolkens from comment #3) > (In reply to Ionen Wolkens from comment #1) > > Also affects clang, which can also be selected as a kernel compiler. > Or not, I see it's there in postrm already -- assumed that if gcc doesn't do > it then clang probably didn't either. On that note, are you sure it didn't get cleaned? I just happened to depclean gcc-13, and I seen right after: Cleaning up masquerade for ccache ... removed 'g++-13' removed 'gcc-13' removed 'x86_64-pc-linux-gnu-g++-13' removed 'x86_64-pc-linux-gnu-gcc-13' And they are indeed gone. Then again maybe there was something up with older 12 and this is already fixed.
commit c4cd0691bd4fdef1c7eca9dc27f4dffb9f43f593 Author: Michał Górny <mgorny@gentoo.org> Date: Thu Aug 10 23:18:22 2017 +0200 toolchain.eclass: Update masquerades via dev-util/shadowman postinst/rm The only possibly relevant thing I could think of is commit 6302dd47e23ee32cfcb446355704ba8bc61b668e Author: Sam James <sam@gentoo.org> Date: Mon Sep 25 01:05:20 2023 +0100 toolchain.eclass: fix should_we_gcc_config for major-version slotting Reported by the-horo on IRC. For example, with slot as major version: ``` $ gcc-config -c x86_64-pc-linux-gnu x86_64-pc-linux-gnu-13 $ gcc-config -S x86_64-pc-linux-gnu-13 x86_64-pc-linux-gnu 13 ``` so we're indeed comparing 13 with 13.2 and hence we decide to run gcc-config unnecessarily because we think it's a major version change. Fix that by taking into account tc_use_major_version_only and comparing based on GCCMAJOR for that case. Bug: https://bugs.gentoo.org/865835 Bug: https://bugs.gentoo.org/873505 Reported-by: the-horo Closes: https://github.com/gentoo/gentoo/pull/33042 Signed-off-by: Sam James <sam@gentoo.org>
