Created attachment 862361 [details]
emerge --info output
Kernel version: 6.3.3 (gentoo-sources)
Steps to reproduce: Compile gentoo-sources with clang and emerge virtualbox-modules.
app-emulation/virtualbox-modules-7.0.8:0/7.0 can't compile with a clang compiled gentoo kernel.
* Warning: building virtualbox-modules with a clang-built kernel is experimental.
See you have -flto, is the kernel also using lto? (build log would help)
The current ebuild does not consider llvm-nm and that breaks with lto -- fwiw, this will be eventually fixed by https://github.com/gentoo/gentoo/pull/31154
Meanwhile you can try to set LLVM=1 in your environment when emerging virtualbox-modules
(In reply to Ionen Wolkens from comment #1)
> See you have -flto, is the kernel also using lto? (build log would help)
> The current ebuild does not consider llvm-nm and that breaks with lto --
> fwiw, this will be eventually fixed by
> Meanwhile you can try to set LLVM=1 in your environment when emerging
Yes the kernel is built with clang full lto. I added my kernel .config if that may help. Meanwhile I'll set the environment to LLVM=1.
Created attachment 862684 [details]
Linux kernel config
Can you also attach the build.log? I use a clang kernel with lto and it compiles fine for me. I also tried with gentoo-sources-6.3.3.
That warning you posted is harmless.
Perhaps only happen with thinlto, haven't checked full. Do make sure you don't have LLVM=1 set if trying to reproduce that (but still with a LLVM=1 + LTO_CLANG_THIN kernel), e.g. errors like:
./scripts/check-local-export: x86_64-pc-linux-gnu-nm failed
make: *** [scripts/Makefile.build:250: /tmp/portage/app-emulation/virtualbox-modules-7.0.8/work/vboxdrv/SUPDrvSem
.o] Error 143
(note that it's not using llvm-nm, it does use in clang though)
May perhaps need clang-16 or something given this /used/ to work with binutils' nm afaik, I'm not sure when it stopped.
Doesn't happen with e.g. nvidia-drivers given it switches the full toolchain both ways as needed (without needing to set LLVM=1 that is), but linux-mod-r1 does that too and won't require worrying about this in ebuilds anymore. I'll probably go ahead and push it in ~2 days or so.
Anyhow, yeah, still need the build.log to know what's actually going on in this case, this was just a guess.
Oh and ftr I was testing with kernel 6.1.28
Oh right, maybe it's just because I don't keep llvmgold around anymore :) It's possible it's using it.