Created attachment 862361 [details] emerge --info output Reproducable: Always Kernel version: 6.3.3 (gentoo-sources) global ~amd64 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 > https://github.com/gentoo/gentoo/pull/31154 > > Meanwhile you can try to set LLVM=1 in your environment when emerging > virtualbox-modules 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 /tmp/portage/app-emulation/virtualbox-modules-7.0.8/work/vboxdrv/SUPDrvSem.o ./scripts/check-local-export: x86_64-pc-linux-gnu-nm failed make[3]: *** [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.
