I am assuming this is related to the newly-added support for Dtrace in Gentoo: if CONFIG_CTF is selected in the kernel config under "Library Support" and dev-debug/dtrace hasn't been merged yet, then one gets this failure when compiling the kernel: > HOSTCC scripts/ctf/ctfarchive.o > HOSTCC scripts/ctf/modules_builtin.o > scripts/ctf/ctfarchive.c:21:10: fatal error: ctf-api.h: No such file or directory > 21 | #include <ctf-api.h> > | ^~~~~~~~~~~ > compilation terminated. > make[3]: *** [scripts/Makefile.host:131: scripts/ctf/ctfarchive.o] Error 1 > make[3]: *** Waiting for unfinished jobs.... > make[2]: *** [scripts/Makefile.build:480: scripts/ctf] Error 2 > make[2]: *** Waiting for unfinished jobs.... I looked high and low for "ctf-api.h" in the kernel proper, at first thinking it was something new to the kernel, but now I'm somewhat certain it's a file that's installed by Dtrace itself. I got hung up on the hard dependency on Wireshark, so I didn't actually install Dtrace to find out. But one of my FreeBSD systems has a "/usr/include/sys/ctf_api.h" header file w/ a CDDL-license clause and Sun Microsystems branding in it, so it tracks. It might make sense to put the Dtrace support patch (2995_dtrace-6.6_p2.patch) behind a USE flag on gentoo-sources, along with a DEPEND against dev-debug/dtrace, because the hard dependency on Wireshark can make Dtrace a bit of a heavyweight, especially for headless systems.
It's actually from sys-libs/binutils-libs. But we could improve the Kconfig help text: """ +# +# CTF support is select'ed if needed +# +config CTF + bool "Compact Type Format generation" + depends on HAVE_CTF_TOOLCHAIN + help + Emit a compact, compressed description of the kernel's datatypes and + global variables into the vmlinux.ctfa archive (for in-tree modules) + or into .ctf sections in kernel modules (for out-of-tree modules). """ As for Wireshark: can you file a separate bug for that? I agree we should see about making that conditional.
I wonder why the HAVE_CTF_TOOLCHAIN check was (wrongly) true for you if you lack the header.
(In reply to Sam James from comment #2) > I wonder why the HAVE_CTF_TOOLCHAIN check was (wrongly) true for you if you > lack the header. Hmm, that's a good question: > config HAVE_CTF_TOOLCHAIN > def_bool $(cc-option,-gctf) && $(ld-option,-lbfd -liberty -lctf -lbfd -liberty -lz -ldl -lc -o /dev/null) > depends on CC_IS_GCC > help > GCC and binutils support CTF generation. > I tested compiling a simple C file w/ gcc and passed it -gctf, and it compiled w/o complaint. For ld, I ran the option chain from the test, and it only complains about a start address, but returns 0: > # ld -lbfd -liberty -lctf -lbfd -liberty -lz -ldl -lc -o /dev/null > ld: warning: cannot find entry symbol _start; not setting start address > # echo $? > 0 I checked, and I do not have binutils-libs installed at the moment, either. So not sure why the missing header file doesn't affect these two tests. Only seems to get tripped up when you actually try to #include it in a source file.
