Re: [PATCH v2 3/4] bpftool: Add explicitly sequenced -lzstd to libbfd feature fallback

[Quentin Monnet <qmo@kernel.org>]

2026-09-10 08:37 UTC-0700 ~ Ian Rogers <irogers@google.com>
> On Thu, Sep 10, 2026 at 2:20 AM Quentin Monnet <qmo@kernel.org> wrote:
>>
>> On 09/09/2026 21:41, Ian Rogers wrote:
>>> Distributions like Fedora currently ship a statically compiled binutils
>>> libbfd that natively depends on zstd to decompress sections (e.g.
>>> undefined reference to 'ZSTD_decompress').
>>>
>>> Extend the newly supplemented libbfd-liberty-z-zstd feature probe into
>>> bpftool's Makefile so it can natively build against static binutils
>>> distributions.
>>>
>>> Signed-off-by: Ian Rogers <irogers@google.com>
>>> Assisted-by: Antigravity:gemini-3.1-pro
>>> ---
>>>  tools/bpf/bpftool/Makefile | 4 ++++
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
>>> index b0f7168e7943..1cac4508eb0c 100644
>>> --- a/tools/bpf/bpftool/Makefile
>>> +++ b/tools/bpf/bpftool/Makefile
>>> @@ -125,6 +125,7 @@ FEATURE_TESTS += libcap
>>>  FEATURE_TESTS += libbfd
>>>  FEATURE_TESTS += libbfd-liberty
>>>  FEATURE_TESTS += libbfd-liberty-z
>>> +FEATURE_TESTS += libbfd-liberty-z-zstd
>>>  FEATURE_TESTS += disassembler-four-args
>>>  FEATURE_TESTS += disassembler-init-styled
>>>  FEATURE_TESTS += libelf-zstd
>>> @@ -135,6 +136,7 @@ FEATURE_DISPLAY += libcap
>>>  FEATURE_DISPLAY += libbfd
>>>  FEATURE_DISPLAY += libbfd-liberty
>>>  FEATURE_DISPLAY += libbfd-liberty-z
>>> +FEATURE_DISPLAY += libbfd-liberty-z-zstd
>>>  endif
>>>
>>>  check_feat := 1
>>> @@ -201,6 +203,8 @@ else
>>>      LIBS += -lbfd -ldl -lopcodes -liberty
>>>    else ifeq ($(feature-libbfd-liberty-z),1)
>>>      LIBS += -lbfd -ldl -lopcodes -liberty -lz
>>> +  else ifeq ($(feature-libbfd-liberty-z-zstd),1)
>>> +    LIBS += -lbfd -ldl -lopcodes -liberty -lz -lzstd
>>>    endif
>>>
>>>    # If one of the above feature combinations is set, we support libbfd
>>
>>
>> Hi Ian, thanks for this!
>>
>> Just checking: my understanding is that if libbfd depends on libzstd,
>> then it always also depends on zlib, so we never need to check some
>> variant such as "feature-libbfd-liberty-zstd" (without the "-z"), is
>> this correct?
> 
> Hi,
> 
> You make a good point. Normally we want to use pkg-config to get the
> libraries necessary for a dependency. Unfortunately pkg-config is
> generally broken around binutils/libbfd. This is why we have all of
> these tests to determine the list of libraries we need to link with
> libbfd for things to work, which pkg-config normally provides. It is
> perfectly possible to build libbfd with libzstd and without libz, but
> currently, we haven't encountered a distribution doing this. I can
> imagine a memory hardened future where libz has become zlib-rs that
> conveniently provides C headers.
> 
> For perf we don't build with binutils by default; this matter is only
> an issue for our build tests. We don't depend on libbfd because its
> GPLv3+ license isn't compatible with perf's GPLv2 license, which would
> create an undistributable binary. This isn't an issue for bpftool
> because its BSD 2-clause license is compatible with libbfd. In perf


We still have some issues for bpftool related to libbfd: for Debian
packaging, building against the shared libbfd is "Not Allowed" [0]. This
was one of the motivations for introducing the use of LLVM as an
alternative dependency. I didn't know elfutils offered a similar
feature, I should look into it.

[0] https://packages.debian.org/sid/amd64/binutils-dev


> we've been replacing libbfd based functionality with that in elfutils.
> libLLVM is another consideration, but it's generally too heavyweight
> for the effort to be worthwhile (it is generally large, distributions
> don't want a dependency on it, and it runs many initialization hooks
> at startup that don't benefit perf). Hopefully elfutils can provide a
> stable API for its disassembler (libasm) as that would cover pretty
> much everything perf needs without requiring us to fork objdump, use
> libcapstone or use libLLVM.
> 
> Anyway, we could add another flavor (zstd without libz) to the feature
> tests for libbfd but since this isn't currently an issue I think we
> can cross our fingers for binutils to fix pkg-config or for other
> tools in the kernel, like perf, to migrate away from the use of
> libbfd. If we add every flavor of libbfd's dependencies, it feels like
> a lot of build clutter (imo) and I don't know where we stop.


Thanks for all the context, very much appreciated! I agree, sticking to
the zlib + zstd variant sounds like a good option for now, thanks.

Acked-by: Quentin Monnet <qmo@kernel.org>