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 Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:23 GMT
Opened by Max (qtmax) - Monday, 15 May 2023, 19:03 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:23 GMT
|
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
Closed by Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:23 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/zstd/issues/1
Saturday, 25 November 2023, 20:23 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/zstd/issues/1
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
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?
It's a good question. It appears to have been introduced because of "prelink" in
FS#40364. But prelink is now dead and buried and here we are stuck with libelf static libs in 2023. See? This is one of the problems with static libs. We now have no idea which packages might be using the libelf static libs because it's impossible to track (at least AFAIK - anyone else know?). The only thing I can think of that might need it is "qemu-user-static", but I'm only guessing because ISTR it's the QEMU *system* binaries that need libelf.