On Tue, Mar 25, 2025 at 11:09:24AM +0000, Quentin Monnet wrote: > 2025-03-25 16:02 UTC+0530 ~ Venkat Rao Bagalkote <venka...@linux.ibm.com> > > Greetings!!! > > > > > > bpftool fails to complie on linux-next-20250324 repo. > > > > > > Error: > > > > make: *** No rule to make target 'bpftool', needed by '/home/linux/ > > tools/testing/selftests/bpf/tools/include/vmlinux.h'. Stop. > > make: *** Waiting for unfinished jobs..... > > > Thanks! Would be great to have a bit more context on the error (and on > how to reproduce) for next time. Bpftool itself seems to compile fine, > the error shows that it's building it from the context of the selftests > that seems broken. > > Yes, selftest build for BPF fails. ## pwd /linux/tools/testing/selftests/bpf
# make -j 33 make: *** No rule to make target 'bpftool', needed by '/home/upstreamci/linux/tools/testing/selftests/bpf/tools/include/vmlinux.h'. Stop. make: *** Waiting for unfinished jobs.... > > Git bisect points to commit: 8a635c3856ddb74ed3fe7c856b271cdfeb65f293 as > > first bad commit. > > Thank you Venkat for the bisect! > > On a quick look, that commit introduced a definition for BPFTOOL in > tools/scripts/Makefile.include: > > diff --git a/tools/scripts/Makefile.include .../Makefile.include > index 0aa4005017c7..71bbe52721b3 100644 > --- a/tools/scripts/Makefile.include > +++ b/tools/scripts/Makefile.include > @@ -91,6 +91,9 @@ LLVM_CONFIG ?= llvm-config > LLVM_OBJCOPY ?= llvm-objcopy > LLVM_STRIP ?= llvm-strip > > +# Some tools require bpftool > +BPFTOOL ?= bpftool > + > ifeq ($(CC_NO_CLANG), 1) > EXTRA_WARNINGS += -Wstrict-aliasing=3 > > But several utilities or selftests under tools/ include > tools/scripts/Makefile.include _and_ use their own version of the > $(BPFTOOL) variable, often assigning only if unset, for example in > tools/testing/selftests/bpf/Makefile: > > BPFTOOL ?= $(DEFAULT_BPFTOOL) > > My guess is that the new definition from Makefile.include overrides this > with simply "bpftool" as a value, and the Makefile fails to build it as > a result. > > If I guessed correctly, one workaround would be to rename the variable > in Makefile.include (and in whatever Makefile now relies on it) into > something that is not used in the other Makefiles, for example > BPFTOOL_BINARY. > > Please copy the BPF mailing list on changes impacting BPF tooling (or > for BPF-related patchsets in general). > > Thanks, > Quentin Yes you are right that the new definition from Makefile.include overrides this with simply "bpftool" as a value, and the Makefile in bpf selftest fails to build it as a result. But the main cause is that it is not able to locate the bpftool binary. So, is it good idea to both rename this variable in Makefile.include and use: BPFTOOL ?= /usr/sbin/bpftool This is the link to patch that is impacting: https://lore.kernel.org/all/20250218145859.27762-3-tglo...@redhat.com/ Thanks, Saket
