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

[Ian Rogers]

On Thu, Sep 10, 2026 at 2:20 AM Quentin Monnet <qmo@xxxxxxxxxx> 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@xxxxxxxxxx>
> > 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'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,
Ian

> Quentin