linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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


  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).