From: Ihor Solodrai <ihor.solodrai@linux.dev>
To: Vitaly Chikunov <vt@altlinux.org>
Cc: bot+bpf-ci@kernel.org, ast@kernel.org, andrii@kernel.org,
daniel@iogearbox.net, eddyz87@gmail.com, olsajiri@gmail.com,
yatsenko@meta.com, alexis.lothore@bootlin.com,
ameryhung@gmail.com, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-team@meta.com,
martin.lau@kernel.org, yonghong.song@linux.dev, clm@meta.com
Subject: Re: [PATCH bpf v3 01/15] selftests/bpf: Pass through build flags to bpftool and resolve_btfids
Date: Mon, 2 Mar 2026 14:42:11 -0800 [thread overview]
Message-ID: <de42bb10-dafd-45da-97fe-b59be487f30b@linux.dev> (raw)
In-Reply-To: <aaXwaMCIm9UZUx9O@altlinux.org>
On 3/2/26 12:27 PM, Vitaly Chikunov wrote:
> Ihor,
>
> On Mon, Mar 02, 2026 at 10:01:59AM -0800, Ihor Solodrai wrote:
>> On 3/2/26 7:22 AM, Vitaly Chikunov wrote:
>>> On Fri, Feb 20, 2026 at 08:23:51PM -0800, Ihor Solodrai wrote:
>>>> On 2/20/26 2:57 PM, bot+bpf-ci@kernel.org wrote:
>>>>>> diff --git a/tools/bpf/resolve_btfids/Makefile b/tools/bpf/resolve_btfids/Makefile
>>>>>> index 1733a6e93a07..ef083602b73a 100644
>>>>>> --- a/tools/bpf/resolve_btfids/Makefile
>>>>>> +++ b/tools/bpf/resolve_btfids/Makefile
>>>>>> @@ -65,6 +65,9 @@ $(BPFOBJ): $(wildcard $(LIBBPF_SRC)/*.[ch] $(LIBBPF_SRC)/Makefile) | $(LIBBPF_OU
>>>>>> LIBELF_FLAGS := $(shell $(HOSTPKG_CONFIG) libelf --cflags 2>/dev/null)
>>>>>> LIBELF_LIBS := $(shell $(HOSTPKG_CONFIG) libelf --libs 2>/dev/null || echo -lelf)
>>>>>>
>>>>>> +ZLIB_LIBS := $(shell $(HOSTPKG_CONFIG) zlib --libs 2>/dev/null || echo -lz)
>>>>>> +ZSTD_LIBS := $(shell $(HOSTPKG_CONFIG) libzstd --libs 2>/dev/null || echo -lzstd)
>>>>>
>>>>> The "|| echo -lzstd" fallback makes zstd an unconditional link
>>>>> dependency. On systems where libzstd-dev is not installed, pkg-config
>>>>> fails and the fallback provides -lzstd, but the linker cannot find the
>>>>> library and the build fails.
>>>>>
>>>>> bpftool handles the same transitive dependency conditionally via a
>>>>> feature test:
>>>>>
>>>>> tools/bpf/bpftool/Makefile:
>>>>> ifeq ($(feature-libelf-zstd),1)
>>>>> LIBS += -lzstd
>>>>> LIBS_BOOTSTRAP += -lzstd
>>>>> endif
>>>>>
>>>>> Would it be safer to drop the fallback here so ZSTD_LIBS is empty
>>>>> when zstd is not available?
>>>>>
>>>>> ZSTD_LIBS := $(shell $(HOSTPKG_CONFIG) libzstd --libs 2>/dev/null)
>>>>>
>>>>> This would still link zstd when present (needed for the static linking
>>>>> case where libelf.a pulls in ZSTD symbols from elf_compress.o), but
>>>>> avoid breaking dynamic builds on systems without libzstd-dev.
>>>>
>>>> [...]
>>>>
>>>>
>>>> So, while AI may be technically correct that the build will fail if
>>>> libelf is installed and libzstd is not, it seems a far-fetched
>>>> situation, given that libelf depends on libzstd.
>>>
>>> This is not far-fetched, and we have build failure for v7.0-rc2 due to
>>> this.
>>>
>>> ld: cannot find -lzstd: No such file or directory
>>>
>>> Even though libelf is linked with libzstd, this does not imply
>>> libzstd-devel (with headers and so library) is there when building.
>>
>> Does AI's suggestion make sense in your case then?
>> That is, make ZSTD_LIBS empty in case pkg-config didn't find libzstd?
>>
>> I'm happy to fix this, the build shouldn't fail unless it must.
>>
>> But I am curious how and why an environment building Linux with BTF
>> (requiring build and run of resolve_btfids), which needs libelf-dev
>> and presumably its dependencies, would exclude/avoid installing
>> libzstd-dev?
>
> Are you providing -lzstd just to link with libelf? I don't think you need to
An explicit -lzstd flag was added to enable a static build [1].
> care about zstd in that case. libelf is already linked with libzstd. If you
> don't use libzstd functions yourself you don't need to link with -lzstd.
>
> Example build without -lzstd:
>
> builder@x86_64:~/RPM/BUILD/kernel-image-7.0-rc2$ grep zstd tools/bpf/resolve_btfids/Makefile
> ZSTD_LIBS := $(shell $(HOSTPKG_CONFIG) libzstd --libs 2>/dev/null)
>
> builder@x86_64:~/RPM/BUILD/kernel-image-7.0-rc2$ ldd ./tools/bpf/resolve_btfids/resolve_btfids
> linux-vdso.so.1 (0x00007ff8b2329000)
> libelf.so.1 => /lib64/libelf.so.1 (0x00007ff8b2287000)
> libz.so.1 => /lib64/libz.so.1 (0x00007ff8b2269000)
> libc.so.6 => /lib64/libc.so.6 (0x00007ff8b206e000)
> libzstd.so.1 => /lib64/libzstd.so.1 (0x00007ff8b1fc8000)
> /lib64/ld-linux-x86-64.so.2 (0x00007ff8b232b000)
> builder@x86_64:~/RPM/BUILD/kernel-image-7.0-rc2$ rpm -q libzstd
> libzstd-1.5.5-alt2.x86_64
> builder@x86_64:~/RPM/BUILD/kernel-image-7.0-rc2$ rpm -q libzstd-devel
> package libzstd-devel is not installed
>
> lib*-devel/-dev packages only required if your source is directly using the
> target lib, in other causes this is already handled.
The issue that AI has raised is whether to leave -lzstd link flag by
default or not. I decided to leave it on the assumption that the
environments building Linux with BTF (hence building and running
resovle_btfids) would have libelf-dev installed (because -lelf has
been a requirement forever [2]), and libzstd-dev is its dependency.
I checked a few recent distros, all of them have libzstd-dev as a
direct dependency of libelf-dev, which supports my assumption:
# Fedora
$ dnf repoquery --providers-of=depends elfutils-libelf-devel
Updating and loading repositories:
Repositories loaded.
elfutils-libelf-0:0.194-1.fc43.i686
elfutils-libelf-0:0.194-1.fc43.x86_64
libzstd-devel-0:1.5.7-2.fc43.i686
libzstd-devel-0:1.5.7-2.fc43.x86_64
pkgconf-pkg-config-0:2.3.0-3.fc43.i686
pkgconf-pkg-config-0:2.3.0-3.fc43.x86_64
zlib-ng-compat-devel-0:2.3.3-1.fc43.i686
zlib-ng-compat-devel-0:2.3.3-1.fc43.x86_64
# Ubuntu
$ apt info libelf-dev
Package: libelf-dev
Version: 0.190-1.1ubuntu0.1
Priority: optional
Section: libdevel
Source: elfutils
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Debian Elfutils Maintainers <debian-gcc@lists.debian.org>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 385 kB
Depends: libelf1t64 (= 0.190-1.1ubuntu0.1), zlib1g-dev, libzstd-dev
Conflicts: libelfg0-dev
[...]
# Debian
$ apt info libelf-dev
Package: libelf-dev
Version: 0.192-4
Priority: optional
Section: libdevel
Source: elfutils
Maintainer: Debian Elfutils Maintainers <debian-gcc@lists.debian.org>
Installed-Size: 420 kB
Depends: libelf1t64 (= 0.192-4), zlib1g-dev, libzstd-dev
Conflicts: libelfg0-dev
[...]
Of course it's plausible to have a system where libelf-dev is present
while libzstd-dev is not, as demonstrated by you running one.
Anyways this is easy to fix, I'll send a patch shortly.
[1] https://lore.kernel.org/bpf/4ff82800-2daa-4b9f-95a9-6f512859ee70@linux.dev/
[2] https://lore.kernel.org/bpf/20200711215329.41165-2-jolsa@kernel.org/
>
> Thanks,
>
>>
>> Thanks.
>>
>>>
>>> Thanks,
>>>
>>>>
>>>> I think we can leave the default -lzstd to have an explicit
>>>> dependency in the Makefile.
>>>>
>>>>
>>>>>
>>>>> [ ... ]
>>
next prev parent reply other threads:[~2026-03-02 22:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-20 22:25 [PATCH bpf v3 00/15] selftests/bpf: Fixes for userspace ASAN Ihor Solodrai
2026-02-20 22:25 ` [PATCH bpf v3 01/15] selftests/bpf: Pass through build flags to bpftool and resolve_btfids Ihor Solodrai
2026-02-20 22:57 ` bot+bpf-ci
2026-02-21 4:23 ` Ihor Solodrai
2026-03-02 15:22 ` Vitaly Chikunov
2026-03-02 18:01 ` Ihor Solodrai
2026-03-02 20:27 ` Vitaly Chikunov
2026-03-02 22:42 ` Ihor Solodrai [this message]
2026-03-03 4:01 ` Vitaly Chikunov
2026-02-20 22:25 ` [PATCH bpf v3 02/15] resolve_btfids: Fix memory leaks reported by ASAN Ihor Solodrai
2026-02-20 22:25 ` [PATCH bpf v3 03/15] selftests/bpf: Add DENYLIST.asan Ihor Solodrai
2026-02-20 22:25 ` [PATCH bpf v3 04/15] selftests/bpf: Refactor bpf_get_ksyms() trace helper Ihor Solodrai
2026-02-20 22:25 ` [PATCH bpf v3 05/15] selftests/bpf: Fix memory leaks in tests Ihor Solodrai
2026-02-20 22:25 ` [PATCH bpf v3 06/15] selftests/bpf: Fix cleanup in check_fd_array_cnt__fd_array_too_big() Ihor Solodrai
2026-02-20 22:25 ` [PATCH bpf v3 07/15] veristat: Fix a memory leak for preset ENUMERATOR Ihor Solodrai
2026-02-20 22:25 ` [PATCH bpf v3 08/15] selftests/bpf: Fix use-after-free in xdp_metadata test Ihor Solodrai
2026-02-20 22:25 ` [PATCH bpf v3 09/15] selftests/bpf: Fix double thread join in uprobe_multi_test Ihor Solodrai
2026-02-20 22:25 ` [PATCH bpf v3 10/15] selftests/bpf: Fix resource leaks caused by missing cleanups Ihor Solodrai
2026-02-20 22:26 ` [PATCH bpf v3 11/15] selftests/bpf: Free bpf_object in test_sysctl Ihor Solodrai
2026-02-20 22:26 ` [PATCH bpf v3 12/15] selftests/bpf: Fix array bounds warning in jit_disasm_helpers Ihor Solodrai
2026-02-20 22:26 ` [PATCH bpf v3 13/15] selftests/bpf: Fix out-of-bounds array access bugs reported by ASAN Ihor Solodrai
2026-02-20 22:26 ` [PATCH bpf v3 14/15] selftests/bpf: Check BPFTOOL env var in detect_bpftool_path() Ihor Solodrai
2026-02-20 22:26 ` [PATCH bpf v3 15/15] selftests/bpf: Don't override SIGSEGV handler with ASAN Ihor Solodrai
2026-02-21 0:52 ` Eduard Zingerman
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=de42bb10-dafd-45da-97fe-b59be487f30b@linux.dev \
--to=ihor.solodrai@linux.dev \
--cc=alexis.lothore@bootlin.com \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=olsajiri@gmail.com \
--cc=vt@altlinux.org \
--cc=yatsenko@meta.com \
--cc=yonghong.song@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.