From: Saket Kumar Bhaskar <skb99@linux.ibm.com>
To: Quentin Monnet <qmo@qmon.net>
Cc: Venkat Rao Bagalkote <venkat88@linux.ibm.com>,
Hari Bathini <hbathini@linux.ibm.com>, bpf <bpf@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linuxppc-dev@lists.ozlabs.org, jkacur@redhat.com,
lgoncalv@redhat.com, gmonaco@redhat.com, williams@redhat.com,
tglozar@redhat.com, rostedt@goodmis.org
Subject: Re: [linux-next-20250324]/tool/bpf/bpftool fails to complie on linux-next-20250324
Date: Tue, 25 Mar 2025 17:14:55 +0530 [thread overview]
Message-ID: <Z+KXN0KjyHlQPLUj@linux.ibm.com> (raw)
In-Reply-To: <8b0b2a41-203d-41f8-888d-2273afb877d0@qmon.net>
On Tue, Mar 25, 2025 at 11:09:24AM +0000, Quentin Monnet wrote:
> 2025-03-25 16:02 UTC+0530 ~ Venkat Rao Bagalkote <venkat88@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-tglozar@redhat.com/
Thanks,
Saket
next prev parent reply other threads:[~2025-03-25 11:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-25 10:32 [linux-next-20250324]/tool/bpf/bpftool fails to complie on linux-next-20250324 Venkat Rao Bagalkote
2025-03-25 11:09 ` Quentin Monnet
2025-03-25 11:44 ` Saket Kumar Bhaskar [this message]
2025-03-25 12:04 ` Quentin Monnet
2025-03-25 14:59 ` Tomas Glozar
2025-03-25 15:09 ` Tomas Glozar
2025-03-25 15:27 ` Quentin Monnet
2025-03-25 15:45 ` Tomas Glozar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z+KXN0KjyHlQPLUj@linux.ibm.com \
--to=skb99@linux.ibm.com \
--cc=bpf@vger.kernel.org \
--cc=gmonaco@redhat.com \
--cc=hbathini@linux.ibm.com \
--cc=jkacur@redhat.com \
--cc=lgoncalv@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=qmo@qmon.net \
--cc=rostedt@goodmis.org \
--cc=tglozar@redhat.com \
--cc=venkat88@linux.ibm.com \
--cc=williams@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).