From: sashiko-bot@kernel.org
To: "hadrien Patte" <hadrien.patte@protonmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next] bpftool: Resolve libcrypto link flags via pkg-config
Date: Fri, 01 May 2026 18:11:03 +0000 [thread overview]
Message-ID: <20260501181104.265E9C2BCB4@smtp.kernel.org> (raw)
In-Reply-To: <20260501175829.9833-1-hadrien.patte@protonmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Hardcoding `pkg-config` directly executes the host's pkg-config environment, breaking cross-compilation.
- [High] The resolved `libcrypto` link flags (`CRYPTO_LIBS`) are improperly shared between the target build (`bpftool`) and the host-compiled bootstrap build (`bpftool-bootstrap`), causing linker failures in cross-compilation.
- [Medium] Using `findstring` to detect the `-static` flag in `EXTRA_LDFLAGS` yields false positives due to substring matching.
--
commit aa775c0d6fcc0ef9be036e5edb76f38528db0dd3
Author: Hadrien Patte <hadrien.patte@protonmail.com>
bpftool: Resolve libcrypto link flags via pkg-config
This patch modifies the bpftool Makefile to resolve libcrypto linker flags
using pkg-config instead of hardcoding them. It also attempts to pass --static
to pkg-config if a static build is requested via EXTRA_LDFLAGS.
> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
> --- 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)),)
Does this findstring check cause a regression by matching other flags?
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 we use the filter function instead to match the exact word, similar to
other BPF makefiles?
> + CRYPTO_LIBS := $(shell pkg-config --libs --static libcrypto 2>/dev/null)
> + else
> + CRYPTO_LIBS := $(shell pkg-config --libs 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?
> + endif
> + CRYPTO_LIBS := $(if $(CRYPTO_LIBS),$(CRYPTO_LIBS),-lcrypto)
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?
> endif
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260501175829.9833-1-hadrien.patte@protonmail.com?part=1
next prev parent reply other threads:[~2026-05-01 18:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 17:58 [PATCH bpf-next] bpftool: Resolve libcrypto link flags via pkg-config hadrien Patte
2026-05-01 18:11 ` sashiko-bot [this message]
2026-05-01 18:37 ` bot+bpf-ci
2026-05-01 19:40 ` Quentin Monnet
2026-05-01 22:45 ` [PATCH bpf-next v2] " hadrien Patte
2026-05-01 22:58 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260501181104.265E9C2BCB4@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=hadrien.patte@protonmail.com \
--cc=sashiko@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.