Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#78526 - [zstd] should ship with a static library

Attached to Project: Arch Linux
Opened by Max (qtmax) - Monday, 15 May 2023, 19:03 GMT
Last edited by Toolybird (Toolybird) - Monday, 15 May 2023, 20:42 GMT
Task Type Feature Request
Category Packages: Core
Status Assigned
Assigned To Jelle van der Waa (jelly)
Levente Polyak (anthraxx)
Giancarlo Razzolini (grazzolini)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No

Details

Description:

When static linking with libelf, linking fails because of missing libzstd.a (see the steps below).

libelf ships with libelf.a, libelf depends on zlib and zstd (`pkg-config --libs --static libelf` returns `-lelf -lz -lzstd`, and both zlib and zstd are in the package dependencies), zlib ships with libz.a, however, libzstd.a is missing from the zstd package, which breaks the dependency chain.

The zstd package should provide libzstd.a to satisfy the dependency of libelf.

Additional info:
* libelf 0.189-1, zstd 1.5.5-1

Steps to reproduce (minimal):

$ echo '#include <libelf.h>' > /tmp/test.c
$ echo 'int main() { return elf_compress(0, 0, 0); }' >> /tmp/test.c
$ gcc -c /tmp/test.c -o /tmp/test.o
$ gcc -static /tmp/test.o -lelf -lzstd -lz -o /dev/null

The last command fails with:

/usr/bin/ld: cannot find -lzstd: No such file or directory
collect2: error: ld returned 1 exit status

After removing -lzstd, it fails with:

/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../lib/libelf.a(elf_compress.o): in function `__libelf_compress':
(.text+0x103): undefined reference to `ZSTD_createCCtx'
/usr/bin/ld: (.text+0x286): undefined reference to `ZSTD_compressStream2'
/usr/bin/ld: (.text+0x292): undefined reference to `ZSTD_isError'
/usr/bin/ld: (.text+0x2be): undefined reference to `ZSTD_freeCCtx'
/usr/bin/ld: (.text+0x542): undefined reference to `ZSTD_freeCCtx'
/usr/bin/ld: (.text+0x68a): undefined reference to `ZSTD_freeCCtx'
/usr/bin/ld: (.text+0x759): undefined reference to `ZSTD_freeCCtx'
/usr/bin/ld: (.text+0x7b5): undefined reference to `ZSTD_freeCCtx'
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../lib/libelf.a(elf_compress.o):(.text+0x81d): more undefined references to `ZSTD_freeCCtx' follow
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../lib/libelf.a(elf_compress.o): in function `__libelf_decompress':
(.text+0x9f5): undefined reference to `ZSTD_decompress'
/usr/bin/ld: (.text+0x9fe): undefined reference to `ZSTD_isError'
collect2: error: ld returned 1 exit status

The error doesn't happen if /usr/lib/libzstd.a is present.

Real-world use case:

Building the BPF test runner for using it in the vmtest VM requires this patch for static linking: https://github.com/cilium/linux/commit/3a1cef477e3e8e208d2d33035215f1f9d646afef, and static linking fails on Arch Linux due to missing libzstd.a, although libelf.a is present.
This task depends upon

Comment by Toolybird (Toolybird) - Monday, 15 May 2023, 20:41 GMT
In general, static libs in Arch are avoided for security reasons [1]. Just search the bug tracker for the word "static" and you'll find many references e.g  FS#74774  . If Arch doesn't provide the static lib, you'll simply have to work around it. "because libelf.a depends on it" is not a valid reason. In the zstd case, we used to ship it, then it was removed [2]

[1] https://archlinux.org/todo/remove-static-libraries/
[2] https://github.com/archlinux/svntogit-packages/commit/8c5a7de13a35026255e2715c7aa704407c4c40cd
Comment by Max (qtmax) - Tuesday, 16 May 2023, 08:16 GMT
> "because libelf.a depends on it" is not a valid reason.

Why not? To me it sounds like a perfectly valid reason. If Arch provides libelf.a, it should provide its dependencies as well, otherwise libelf.a itself becomes useless, as you can't link a static executable with libelf anyway if its dependencies are missing. (Yes, there is a corner case where you can statically link with libelf, but dynamically link with zstd, but in that case why not link dynamically with libelf as well?)

If the policy is to drop all static libraries, and my BPF use case isn't good enough to override the policy, why keep libelf.a at all? Is it planned for removal too? Or is there some valid use case that Arch supports, where libelf is linked statically to a dynamic binary?

Loading...