Re: [PATCH v3 1/4] tools build: Add explicitly sequenced -lzstd to libbfd feature fallback

[Ian Rogers]

On Tue, Nov 3, 2026 at 9:03 PM <bot+bpf-ci@xxxxxxxxxx> wrote:
>
> > tools build: Add explicitly sequenced -lzstd to libbfd feature fallback
>
> TL;DR: Possible build break at this commit: the libbfd -lzstd fallback is
> removed but no consumer uses the new feature test yet, so perf may fail to
> link and bpftool may lose JIT disassembly.
>
> > diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
> > --- a/tools/build/feature/Makefile
> > +++ b/tools/build/feature/Makefile
>
> [ ... ]
>
> > @@ -249,18 +250,21 @@ $(OUTPUT)test-python-module.bin:
> >       $(BUILD) $(FLAGS_PYTHON_EMBED)
> >
> >  $(OUTPUT)test-libbfd.bin:
> > -     $(BUILD_BFD) || $(BUILD_BFD) -lzstd
> > +     $(BUILD_BFD)
> >
> >  $(OUTPUT)test-libbfd-threadsafe.bin:
> > -     $(BUILD_BFD) || $(BUILD_BFD) -lzstd || $(BUILD_BFD) -liberty || $(BUILD_BFD) -liberty -lz
> > +     $(BUILD_BFD) || $(BUILD_BFD) -liberty || $(BUILD_BFD) -liberty -lz || \
> > +     $(BUILD_BFD) -liberty -lz -lzstd
>
> Can this leave perf and bpftool unable to link libbfd at this commit?

So the concern is that at this commit, not later in the series, a
feature test for a libbfd built with zstd that previously failed to
link in this feature test will now succeed, but the parent Makefile
will not pass the -zstd flag and so break the build. This issue is
fixed later in the series by adding the -lzstd. Will this impact
anything? It will turn one broken build into a different kind of
broken build. I can reengineer the series to maintain bisectability
but this seems like a low priority issue to address.

Thanks,
Ian

> Nothing here reads the new libbfd-liberty-z-zstd result.  Neither
> tools/perf/Makefile.config nor tools/bpf/bpftool/Makefile calls
> feature_check for it or has a branch that uses it.
>
> On a system where "-lbfd -ldl" fails but "-lbfd -ldl -lzstd" links, the
> parent commit gave feature-libbfd=1 through the removed fallback.  Here
> feature-libbfd, feature-libbfd-liberty and feature-libbfd-liberty-z are
> all 0, while feature-libbfd-threadsafe is 1 through the new
> "-liberty -lz -lzstd" fallback.
>
> With BUILD_NONDISTRO=1, perf's Makefile.config then passes the threadsafe
> check but takes none of the EXTLIBS branches:
>
>   ifeq ($(feature-libbfd), 1)
>     EXTLIBS += -lbfd -lopcodes
>   else ifeq ($(feature-libbfd-liberty), 1)
>     EXTLIBS += -lbfd -lopcodes -liberty
>   else ifeq ($(feature-libbfd-liberty-z), 1)
>     EXTLIBS += -lbfd -lopcodes -liberty -lz
>   endif
>
>   CFLAGS += -DHAVE_LIBBFD_SUPPORT
>
> util/libbfd.o is still built, so the perf link can fail with undefined
> references to bfd_openr(), bfd_check_format() and disassembler().  bpftool
> goes down the same chain, silently drops -lbfd and -DHAVE_LIBBFD_SUPPORT,
> and loses JIT disassembly.
>
> The consumers are added later in the series:
>
>   6eb66acc776f ("perf build: Add explicitly sequenced -lzstd to libbfd
>   feature fallback")
>   155513d3a59d ("bpftool: Add explicitly sequenced -lzstd to libbfd
>   feature fallback")
>
> Would it be better to keep the old -lzstd fallback until those consumers
> land, or to reorder or squash so that each commit remains buildable?
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/41774922004