[PATCH bpf-next v2] bpftool: Allow explicitly skip llvm dependency

[PATCH bpf-next v2] bpftool: Allow explicitly skip llvm dependency

[Mykyta Yatsenko]

From: Mykyta Yatsenko <yatsenko@meta.com>

BPF selftests depend on the bpftool. In some environments we may link
bpftool to llvm dynamically and then try to run somewhere where llvm
library is not available.
It's simpler to avoid llvm linking altogether in those cases, this
change allows to do it.

Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
---
 tools/bpf/bpftool/Makefile           | 12 +++++++++++-
 tools/testing/selftests/bpf/Makefile |  2 ++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index 5442073a2e42..f2448e247c5d 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -97,6 +97,11 @@ RM ?= rm -f
 
 FEATURE_USER = .bpftool
 
+# Set SKIP_LLVM=1 to build bpftool without LLVM dependency. When set,
+# bpftool will fall back to libbfd for JIT disassembly (if available),
+# or build without disassembly support.
+SKIP_LLVM ?=
+
 FEATURE_TESTS := clang-bpf-co-re
 FEATURE_TESTS += llvm
 FEATURE_TESTS += libcap
@@ -150,7 +155,12 @@ all: $(OUTPUT)bpftool
 SRCS := $(wildcard *.c)
 
 ifeq ($(feature-llvm),1)
-  # If LLVM is available, use it for JIT disassembly
+ifneq ($(SKIP_LLVM),1)
+HAS_LLVM := 1
+endif
+endif
+
+ifeq ($(HAS_LLVM),1)
   CFLAGS  += -DHAVE_LLVM_SUPPORT
   LLVM_CONFIG_LIB_COMPONENTS := mcdisassembler all-targets
   # llvm-config always adds -D_GNU_SOURCE, however, it may already be in CFLAGS
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index c6bf4dfb1495..4dfff1cfacb6 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -331,6 +331,7 @@ $(DEFAULT_BPFTOOL): $(wildcard $(BPFTOOLDIR)/*.[ch] $(BPFTOOLDIR)/Makefile)    \
 		    OUTPUT=$(HOST_BUILD_DIR)/bpftool/			       \
 		    LIBBPF_OUTPUT=$(HOST_BUILD_DIR)/libbpf/		       \
 		    LIBBPF_DESTDIR=$(HOST_SCRATCH_DIR)/			       \
+		    SKIP_LLVM=$(SKIP_LLVM)				       \
 		    prefix= DESTDIR=$(HOST_SCRATCH_DIR)/ install-bin
 
 ifneq ($(CROSS_COMPILE),)
@@ -343,6 +344,7 @@ $(CROSS_BPFTOOL): $(wildcard $(BPFTOOLDIR)/*.[ch] $(BPFTOOLDIR)/Makefile)	\
 		    OUTPUT=$(BUILD_DIR)/bpftool/				\
 		    LIBBPF_OUTPUT=$(BUILD_DIR)/libbpf/				\
 		    LIBBPF_DESTDIR=$(SCRATCH_DIR)/				\
+		    SKIP_LLVM=$(SKIP_LLVM)					\
 		    prefix= DESTDIR=$(SCRATCH_DIR)/ install-bin
 endif
 
-- 
2.52.0

Re: [PATCH bpf-next v2] bpftool: Allow explicitly skip llvm dependency

[Quentin Monnet]

2026-01-28 23:34 UTC+0000 ~ Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
> From: Mykyta Yatsenko <yatsenko@meta.com>
> 
> BPF selftests depend on the bpftool. In some environments we may link
> bpftool to llvm dynamically and then try to run somewhere where llvm
> library is not available.
> It's simpler to avoid llvm linking altogether in those cases, this
> change allows to do it.
> 
> Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>


Hi Mykyta, thanks for the patch. Do you have any other solution to make
it work on your environment? We've been rejecting similar changes in the
past, because we don't want to encourage people to strip away the
disassembler when shipping bpftool [0], so I'd rather avoid adding this
if you have another workaround available.

[0] https://lore.kernel.org/bpf/9ffd4b6b-0073-cfef-5889-cb4d0b838f8e@iogearbox.net/

Re: [PATCH bpf-next v2] bpftool: Allow explicitly skip llvm dependency

[Mykyta Yatsenko]

On 1/29/26 17:34, Quentin Monnet wrote:
> 2026-01-28 23:34 UTC+0000 ~ Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
>> From: Mykyta Yatsenko <yatsenko@meta.com>
>>
>> BPF selftests depend on the bpftool. In some environments we may link
>> bpftool to llvm dynamically and then try to run somewhere where llvm
>> library is not available.
>> It's simpler to avoid llvm linking altogether in those cases, this
>> change allows to do it.
>>
>> Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
>
> Hi Mykyta, thanks for the patch. Do you have any other solution to make
> it work on your environment? We've been rejecting similar changes in the
> past, because we don't want to encourage people to strip away the
> disassembler when shipping bpftool [0], so I'd rather avoid adding this
> if you have another workaround available.
>
> [0] https://lore.kernel.org/bpf/9ffd4b6b-0073-cfef-5889-cb4d0b838f8e@iogearbox.net/
we have a workaround, a little ugly, but we can improve that,
anyways, I'm happy to abandon this change.

Re: [PATCH bpf-next v2] bpftool: Allow explicitly skip llvm dependency

[Andrii Nakryiko]

On Thu, Jan 29, 2026 at 9:34 AM Quentin Monnet <qmo@kernel.org> wrote:
>
> 2026-01-28 23:34 UTC+0000 ~ Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
> > From: Mykyta Yatsenko <yatsenko@meta.com>
> >
> > BPF selftests depend on the bpftool. In some environments we may link
> > bpftool to llvm dynamically and then try to run somewhere where llvm
> > library is not available.
> > It's simpler to avoid llvm linking altogether in those cases, this
> > change allows to do it.
> >
> > Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
>
>
> Hi Mykyta, thanks for the patch. Do you have any other solution to make
> it work on your environment? We've been rejecting similar changes in the
> past, because we don't want to encourage people to strip away the
> disassembler when shipping bpftool [0], so I'd rather avoid adding this
> if you have another workaround available.

LLVM is a huge and somewhat problematic dependency, so I think it
makes sense to allow to opt-out of it. Of course this shouldn't be
abused by distro packagers and they should strive to provide
fully-featured build of bpftool. We don't have full control over this,
but let's hope they won't cut corners (either way they can always
apply some ugly local patch, if they decide to cut LLVM dependency).

But for a lot of environments this might not be worthwhile to wire up
LLVM libs. I haven't checked if this is the problem for bpftool's
bootstrap variant, but if LLVM gets pulled in for that one, it's
especially bad :)

>
> [0] https://lore.kernel.org/bpf/9ffd4b6b-0073-cfef-5889-cb4d0b838f8e@iogearbox.net/

Re: [PATCH bpf-next v2] bpftool: Allow explicitly skip llvm dependency

[Quentin Monnet]

2026-01-30 12:46 UTC-0800 ~ Andrii Nakryiko <andrii.nakryiko@gmail.com>
> On Thu, Jan 29, 2026 at 9:34 AM Quentin Monnet <qmo@kernel.org> wrote:
>>
>> 2026-01-28 23:34 UTC+0000 ~ Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
>>> From: Mykyta Yatsenko <yatsenko@meta.com>
>>>
>>> BPF selftests depend on the bpftool. In some environments we may link
>>> bpftool to llvm dynamically and then try to run somewhere where llvm
>>> library is not available.
>>> It's simpler to avoid llvm linking altogether in those cases, this
>>> change allows to do it.
>>>
>>> Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
>>
>>
>> Hi Mykyta, thanks for the patch. Do you have any other solution to make
>> it work on your environment? We've been rejecting similar changes in the
>> past, because we don't want to encourage people to strip away the
>> disassembler when shipping bpftool [0], so I'd rather avoid adding this
>> if you have another workaround available.
> 
> LLVM is a huge and somewhat problematic dependency, so I think it
> makes sense to allow to opt-out of it. Of course this shouldn't be
> abused by distro packagers and they should strive to provide
> fully-featured build of bpftool. We don't have full control over this,
> but let's hope they won't cut corners (either way they can always
> apply some ugly local patch, if they decide to cut LLVM dependency).
> 
> But for a lot of environments this might not be worthwhile to wire up
> LLVM libs. I haven't checked if this is the problem for bpftool's
> bootstrap variant, but if LLVM gets pulled in for that one, it's
> especially bad :)


Hi Andrii,

The bootstrap version doesn't include "bpftool prog" commands, so it
doesn't link against any of the disassembling libraries.

As for opting out from the LLVM disassembler, I understand the lib is an
issue because of the size or when compiling a binary supposed to run on
a different machine, although I do fear this won't help with getting
bpftool shipped with the JIT disassembler.

But if really you want to do this, at least let's do it fully and give
more control for the disassembler dependencies: I think it shouldn't be
just LLVM in this case, there should be a way to opt-out from libbfd as
well, which was problematic for other reasons in the first place, and
probably some mechanism to tell whether to use libbfd or LLVM for the
disassembler when the two are available on the machine.

Quentin

Re: [PATCH bpf-next v2] bpftool: Allow explicitly skip llvm dependency

[Andrii Nakryiko]

On Fri, Jan 30, 2026 at 3:48 PM Quentin Monnet <qmo@kernel.org> wrote:
>
> 2026-01-30 12:46 UTC-0800 ~ Andrii Nakryiko <andrii.nakryiko@gmail.com>
> > On Thu, Jan 29, 2026 at 9:34 AM Quentin Monnet <qmo@kernel.org> wrote:
> >>
> >> 2026-01-28 23:34 UTC+0000 ~ Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
> >>> From: Mykyta Yatsenko <yatsenko@meta.com>
> >>>
> >>> BPF selftests depend on the bpftool. In some environments we may link
> >>> bpftool to llvm dynamically and then try to run somewhere where llvm
> >>> library is not available.
> >>> It's simpler to avoid llvm linking altogether in those cases, this
> >>> change allows to do it.
> >>>
> >>> Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
> >>
> >>
> >> Hi Mykyta, thanks for the patch. Do you have any other solution to make
> >> it work on your environment? We've been rejecting similar changes in the
> >> past, because we don't want to encourage people to strip away the
> >> disassembler when shipping bpftool [0], so I'd rather avoid adding this
> >> if you have another workaround available.
> >
> > LLVM is a huge and somewhat problematic dependency, so I think it
> > makes sense to allow to opt-out of it. Of course this shouldn't be
> > abused by distro packagers and they should strive to provide
> > fully-featured build of bpftool. We don't have full control over this,
> > but let's hope they won't cut corners (either way they can always
> > apply some ugly local patch, if they decide to cut LLVM dependency).
> >
> > But for a lot of environments this might not be worthwhile to wire up
> > LLVM libs. I haven't checked if this is the problem for bpftool's
> > bootstrap variant, but if LLVM gets pulled in for that one, it's
> > especially bad :)
>
>
> Hi Andrii,
>
> The bootstrap version doesn't include "bpftool prog" commands, so it
> doesn't link against any of the disassembling libraries.

ok, that's good, I was hoping we won't bring in unnecessary
dependencies for the bootstrap version of bpftool.

>
> As for opting out from the LLVM disassembler, I understand the lib is an
> issue because of the size or when compiling a binary supposed to run on
> a different machine, although I do fear this won't help with getting
> bpftool shipped with the JIT disassembler.
>
> But if really you want to do this, at least let's do it fully and give
> more control for the disassembler dependencies: I think it shouldn't be
> just LLVM in this case, there should be a way to opt-out from libbfd as
> well, which was problematic for other reasons in the first place, and
> probably some mechanism to tell whether to use libbfd or LLVM for the
> disassembler when the two are available on the machine.

Yeah, absolutely, that makes sense. Mykyta, do you mind looking in
what's the most sensible way to do what Quentin asks? Should we just
have NO_LLVM and NO_BFD switches and take them both into account. If
LLVM or BFD is not explicitly opted-out-from then we'll just prefere
LLVM over BFD?

>
> Quentin

Re: [PATCH bpf-next v2] bpftool: Allow explicitly skip llvm dependency

[Quentin Monnet]

2026-02-03 17:17 UTC-0800 ~ Andrii Nakryiko <andrii.nakryiko@gmail.com>

>> But if really you want to do this, at least let's do it fully and give
>> more control for the disassembler dependencies: I think it shouldn't be
>> just LLVM in this case, there should be a way to opt-out from libbfd as
>> well, which was problematic for other reasons in the first place, and
>> probably some mechanism to tell whether to use libbfd or LLVM for the
>> disassembler when the two are available on the machine.
> 
> Yeah, absolutely, that makes sense. Mykyta, do you mind looking in
> what's the most sensible way to do what Quentin asks? Should we just
> have NO_LLVM and NO_BFD switches and take them both into account. If
> LLVM or BFD is not explicitly opted-out-from then we'll just prefere
> LLVM over BFD?


I'd be OK with that

Quentin