linux-kernel - Re: [PATCH] bpftool: Fix failure with static linkage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEf4BzY-WBs6HmrQBUtq-wCWSUUFruvvw9Fuheb3TfCmqbpj8A@mail.gmail.com>
Date: Tue, 10 Dec 2024 10:26:22 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Quentin Monnet <qmo@...nel.org>
Cc: Namhyung Kim <namhyung@...nel.org>, Leo Yan <leo.yan@....com>, 
	Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, 
	Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>, 
	KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, 
	Jiri Olsa <jolsa@...nel.org>, Nick Terrell <terrelln@...com>, bpf@...r.kernel.org, 
	linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Mahe Tardy <mahe.tardy@...il.com>
Subject: Re: [PATCH] bpftool: Fix failure with static linkage

On Wed, Dec 4, 2024 at 2:08 PM Quentin Monnet <qmo@...nel.org> wrote:
>
> 2024-12-04 13:36 UTC-0800 ~ Namhyung Kim <namhyung@...nel.org>
> > Hi Leo,
> >
> > On Wed, Dec 04, 2024 at 09:30:59PM +0000, Leo Yan wrote:
> >> When building perf with static linkage:
> >>
> >>   make O=/build LDFLAGS="-static" -C tools/perf VF=1 DEBUG=1
> >>   ...
> >>   LINK    /build/util/bpf_skel/.tmp/bootstrap/bpftool
> >>   /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/libelf.a(elf_compress.o): in function `__libelf_compress':
> >>   (.text+0x113): undefined reference to `ZSTD_createCCtx'
> >>   /usr/bin/ld: (.text+0x2a9): undefined reference to `ZSTD_compressStream2'
> >>   /usr/bin/ld: (.text+0x2b4): undefined reference to `ZSTD_isError'
> >>   /usr/bin/ld: (.text+0x2db): undefined reference to `ZSTD_freeCCtx'
> >>   /usr/bin/ld: (.text+0x5a0): undefined reference to `ZSTD_compressStream2'
> >>   /usr/bin/ld: (.text+0x5ab): undefined reference to `ZSTD_isError'
> >>   /usr/bin/ld: (.text+0x6b9): undefined reference to `ZSTD_freeCCtx'
> >>   /usr/bin/ld: (.text+0x835): undefined reference to `ZSTD_freeCCtx'
> >>   /usr/bin/ld: (.text+0x86f): undefined reference to `ZSTD_freeCCtx'
> >>   /usr/bin/ld: (.text+0x91b): undefined reference to `ZSTD_freeCCtx'
> >>   /usr/bin/ld: (.text+0xa12): undefined reference to `ZSTD_freeCCtx'
> >>   /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/libelf.a(elf_compress.o): in function `__libelf_decompress':
> >>   (.text+0xbfc): undefined reference to `ZSTD_decompress'
> >>   /usr/bin/ld: (.text+0xc04): undefined reference to `ZSTD_isError'
> >>   /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/libelf.a(elf_compress.o): in function `__libelf_decompress_elf':
> >>   (.text+0xd45): undefined reference to `ZSTD_decompress'
> >>   /usr/bin/ld: (.text+0xd4d): undefined reference to `ZSTD_isError'
> >>   collect2: error: ld returned 1 exit status
> >>
> >> Building bpftool with static linkage also fails with the same errors:
> >>
> >>   make O=/build -C tools/bpf/bpftool/ V=1
> >>
> >> To fix the issue, explicitly link libzstd.
> >
> > I was about to report exactly the same. :)
>
> Thank you both. This has been reported before [0] but I didn't find the
> time to look into a proper fix.
>
> The tricky part is that static linkage works well without libzstd for
> older versions of elfutils [1], but newer versions now require this
> library. Which means that we don't want to link against libzstd
> unconditionally, or users trying to build bpftool may have to install
> unnecessary dependencies. Instead we should add a new probe under
> tools/build/feature (Note that we already have several combinations in
> there, libbfd, libbfd-liberty, libbfd-liberty-z, and I'm not sure what's
> the best approach in terms of new combinations).
>

So what's the conclusion here? Do we apply this as a fix, or someone
needs to add more feature probing?

> Thanks,
> Quentin
>
>
> [0] https://github.com/libbpf/bpftool/issues/152
> [1] https://github.com/libbpf/bpftool/issues/152#issuecomment-2343131810