Building sys-kernel/gentoo-kernel in a separate ROOT fails due to missing libelf (at least when it's targeting amd64 and x86). Auto-detecting system features: ... libelf: [ OFF ] ... zlib: [ on ] ... bpf: [ on ] No libelf found make[5]: *** [Makefile:287: elfdep] Error 1 make[4]: *** [/var/tmp/portage/sys-kernel/gentoo-kernel-5.10.15/work/linux-5.10/kernel/bpf/preload/Makefile:11: kernel/bpf/preload/libbpf.a] Error 2 make[3]: *** [/var/tmp/portage/sys-kernel/gentoo-kernel-5.10.15/work/linux-5.10/scripts/Makefile.build:496: kernel/bpf/preload] Error 2 make[2]: *** [/var/tmp/portage/sys-kernel/gentoo-kernel-5.10.15/work/linux-5.10/scripts/Makefile.build:496: kernel/bpf] Error 2 make[2]: *** Waiting for unfinished jobs.... There are a couple libraries in tools/build/feature/Makefile that need to be cross-compiled, i.e. declared in DEPEND. It works after installing dev-libs/elfutils or dev-libs/libelf, so adding DEPEND="virtual/libelf" should fix it.
This doesn't seem correct. FWICS all the references to libelf are done via HOSTCC.
I can confirm that kernel/bpf/preload/bpf_preload_umd is built using CC, not HOSTCC. With CROSS_COMPILE="x86_64-pc-linux-gnu-" and HOSTCC defaulted to "gcc", the exact command line is below. > x86_64-pc-linux-gnu-gcc -m64 -o kernel/bpf/preload/bpf_preload_umd kernel/bpf/preload/iterators/iterators.o kernel/bpf/preload/libbpf.a -lelf -lz
This particular failure only affects kernels with CONFIG_BPF_PRELOAD_UMD enabled, so an unconditional entry in DEPEND might be a bit drastic.
Yes, but CONFIG_BPF_PRELOAD_UMD is defined in the config for at least amd64 and x86 with default USE flags (no savedconfig), so this build failure happens by default.
It looks like Fedora sets CONFIG_BPF_PRELOAD_UMD=m, so it may make more sense to add this dependency to the ebuilds that utilize a Fedora kernel config. It might also make sense to enable the dependency only if savedconfig is disabled: if it is enabled, the user may have disabled this kernel option and we should leave it up to them to install any dependencies.
Given that bpf_preload_umd gets linked to cross-compiled shared libraries (libelf and libz), I wonder how this works at runtime. Maybe libelf and zlib need to be in both DEPEND and RDEPEND?
Another simple solution would be to override Fedora's decision and disable CONFIG_BPF_PRELOAD_UMD by default. That avoids the mess entirely.
It probably doesn't need RDEPEND since it doesn't look like bpf_preload_umd is installed in the binpkg. I'm fine with disabling the option. I don't use the functionality.
I created a PR to update base.config.
I'm probably going to add libelf to RDEPEND because of the host tools being installed. While I've no clue how this works (or whether it doesn't) with cross, I guess adding libelf to DEPEND is less of a problem then.
I don't see objtool getting installed by kernel-build.eclass for gentoo-kernel. Is that only installed for the -bin packages? $ qlist gentoo-kernel | grep objtool /usr/src/linux-5.10.16/tools/objtool/Makefile /usr/src/linux-5.10.16/include/linux/objtool.h Running objdump on all packaged files only shows programs linked against libcrypto and libyaml being installed, but they're under scripts and built for CBUILD, so RDEPEND won't help cross in those cases.
It looks like configs disable CONFIG_BPF_PRELOAD_UMD now, so this can be closed.
