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

[bot+bpf-ci]

> 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?

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