Re: [PATCH bpf-next] bpftool: Resolve libcrypto link flags via pkg-config

[bot+bpf-ci]

> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
> index 0febf60e1b64..d9ab860a6cce 100644
> --- a/tools/bpf/bpftool/Makefile
> +++ b/tools/bpf/bpftool/Makefile
> @@ -103,7 +103,17 @@ SKIP_LLVM ?=
>  SKIP_LIBBFD ?=
>  SKIP_CRYPTO ?=
>  ifneq ($(SKIP_CRYPTO),1)
> -  CRYPTO_LIBS := -lcrypto
> +  # Resolve libcrypto link flags via pkg-config so transitive dependencies
> +  # (e.g. libjitterentropy on distros where libcrypto.a references it) are
> +  # included for static builds. Pass --static when the user requested a
> +  # static build via EXTRA_LDFLAGS=-static. Fall back to -lcrypto if
> +  # pkg-config or libcrypto.pc is unavailable.
> +  ifneq ($(findstring -static,$(EXTRA_LDFLAGS)),)

Will this findstring check match other flags unintentionally? If a user
passes flags like -static-pie, -static-libasan, or a custom directory path
like -L/opt/static-libs/, this condition would still evaluate to true and
pass the --static flag to pkg-config for what might be a dynamically linked
build.

Could the filter function be used instead to match the exact word, similar to
other BPF makefiles?

> +    CRYPTO_LIBS := $(shell pkg-config --libs --static libcrypto 2>/dev/null)

Will hardcoding pkg-config directly break cross-compilation environments?
When cross-compiling, invoking pkg-config directly queries the host system's
library paths and might inject host-specific linker flags into the
cross-compiler's link line, leading to architecture mismatches.

Should a target-aware variable like $(PKG_CONFIG) be used here instead?

> +  else
> +    CRYPTO_LIBS := $(shell pkg-config --libs libcrypto 2>/dev/null)
> +  endif
> +  CRYPTO_LIBS := $(if $(CRYPTO_LIBS),$(CRYPTO_LIBS),-lcrypto)
>  endif

Is it safe to share these resolved link flags between the target build and
the host-compiled bootstrap build? Because CRYPTO_LIBS is appended to both
LIBS and LIBS_BOOTSTRAP later in the Makefile, a cross-compilation setup
might fail. It passes the exact same architecture-specific pkg-config output
to both the host and target compilers.

Would it be better to resolve dependencies separately using $(HOSTPKG_CONFIG)
for the bootstrap tool and $(PKG_CONFIG) for the main tool?


---
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/25226582670