Re: [linux-next-20250324]/tool/bpf/bpftool fails to complie on linux-next-20250324

[Tomas Glozar]

Hello Quentin, Venkat, Saket,

Thanks for looking into this.

út 25. 3. 2025 v 13:12 odesílatel Quentin Monnet <qmo@xxxxxxxxxx> napsal:
> If you talk about tools/tracing/rtla/Makefile failing to locate bpftool,
> it's another matter. As far as I understand, the RTLA Makefile assumes
> that bpftool is available from $PATH, this is why the commit introduced
> a probe in tools/build/feature: to ensure that bpftool is installed and
> available. So here again, I don't see the motivation for changing the
> path to the binary (And how do you know it's /usr/sbin/bpftool anyway?
> Some users have it under /usr/local/sbin/, for example). If the intent
> were to compile a bootstrap bpftool to make sure that it's available
> instead then it should replicate what other BPF utilities or selftests
> do, and get rid of the probe. But the commit description for
> 8a635c3856dd indicates that RTLA folks prefer not to compile bpftool and
> rely on it being installed.

Yes, that is correct. The reason why I opted to use the system bpftool
is that bpftool itself has a lot of dependencies, and they would have
to be available at the time of building RTLA. Since RTLA only requires
basic bpftool skeleton generation, and the only "special" feature it
uses is CO-RE which is already quite old now, I don't expect the build
to fail with system bpftool, so I chose to use that to make both the
build dependencies and the RTLA Makefiles simpler.

My commits sets BPFTOOL to bpftool since otherwise, the feature check
would fail, as BPFTOOL wouldn't be defined, since it is not passed to
the feature detection make call. I observed we are doing the same for
Clang and the LLVM toolchain in tools/scripts/Makefile.include;
obviously, there is no problem there, since neither of these are
in-kernel.

Shouldn't the selftests always test the in-tree bpftool instead of the
system one? Let's say there is a stray BPFTOOL environmental variable.
In that case, the tests will give incorrect, possibly false negative
results, if the user is expecting selftests to test what is in the
kernel tree. If it is intended to also be able to test with another
version of bpftool, we can work around the problem by removing the
BPFTOOL definition from tools/scripts/Makefile.include and exporting
it from the rtla Makefiles instead, to make sure the feature tests see
it. The problem with that is, obviously, that future users of the
bpftool feature check would have to do the same, or they would always
fail, unless the user sets BPFTOOL as an environment variable
themselves.

Tomas