coreutils
coreutils copied to clipboard
uutils
0.2.0 prebuilt musl binaries are not statically linked
Tested with https://github.com/uutils/coreutils/releases/download/0.2.0/coreutils-0.2.0-x86_64-unknown-linux-musl.tar.gz
> file coreutils
coreutils: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, stripped
This appears to be a regression, or a change lacking explicit communication, as the previous builds, namely 0.1.0 were statically linked proper.
Something is wrong...
$ ldd coreutils
./coreutils: error while loading shared libraries: /lib64/libc.so: invalid ELF header
https://github.com/uutils/coreutils/compare/0.1.0...0.2.0
There were changes made to .cargo/config.toml:
libstdbuf must be a shared library, so musl libc can't be linked statically
Building without the new rustflags and without the stdbuf feature should allow you to statically link the binary
Should they be statically linked? With libstdbuf.so static linking can't really work.
The fallback of injecting libstdbuf.so into the binary and writing it to /tmp at runtime is a hack IMO
we could disable libstdbuf for this platform
Where does the requirement to static-link everything come from? Will something break with dynamic linking on musl? Musl does support dynamic linking afaik.
IMO, statically linked apps can get rid of the glibc version, meaning we can run them on operating systems like CentOS 7, which has a very old version of glibc.
we could disable libstdbuf for this platform
Where does the requirement to static-link everything come from? Will something break with dynamic linking on musl? Musl does support dynamic linking afaik.
I don't think there is any particular requirement per se, but this is a bit of a misleading question to ask. In the context of musl, users are typically expecting statically-linked tools, as this is one of musl's strong suits and one of the biggest reasons to use it instead of glibc (that is not static-link-friendly for reasons).
So any new feature or introduced dependency, that breaks this convention, is not really expected or welcomed. And especially not in the context of fundamental userspace tools, that would be used in many situations as a rescue mechanism in case of system failure, or otherwise minimal environments that don't need/want to have a dynamic libc present on a system.
So any new feature or introduced dependency, that breaks this convention, is not really expected or welcomed.
well, it is an open source project. Please provides tests to make sure we don't regress if you care about this feature :)
So any new feature or introduced dependency, that breaks this convention, is not really expected or welcomed.
well, it is an open source project. Please provides tests to make sure we don't regress if you care about this feature :)
That is a valid point in general, for any OSS project, but it is rather unrelated to the fact that there was a major packaging change for this release, that was not explicitly communicated in the release notes, breaking customer expectations/assumptions.
It is a bug... if we had known, we would have communicated on this ... (and fix it)
Something is wrong...
$ ldd coreutils ./coreutils: error while loading shared libraries: /lib64/libc.so: invalid ELF header
ldd doesn't work with binaries compiled with musl libc, so the error about invalid ELF header is normal. You need to use e.g. /lib/ld-musl-x86_64.so.1 --list coreutils or readelf -d coreutils | grep NEEDED.
Something is wrong...
$ ldd coreutils ./coreutils: error while loading shared libraries: /lib64/libc.so: invalid ELF headerldd doesn't work with binaries compiled with musl libc, so the error about invalid ELF header is normal. You need to use e.g.
/lib/ld-musl-x86_64.so.1 --list coreutilsorreadelf -d coreutils | grep NEEDED.
Not exactly...
When call ldd with binaries compiled with musl libc, it should report statically linked instead of report invalid ELF header.
For example:
# https://github.com/BurntSushi/ripgrep
$ ldd rg
statically linked
# https://github.com/sharkdp/fd
$ ldd fd
statically linked
@yangyingchao
ldd is just a shell script, that actually calls the system's dynamic linker under the hood. And by default, in most distros it assumes glibc linker by default. And glibc dynamic linker assumes glibc conventions, meaning it will report errors or wrong info when targeting binaries built against musl. Therefore, the errors you described are expected.
To properly check the binaries built against musl you need to use the approach suggested by @Ecordonnier.
More info: https://wiki.musl-libc.org/faq
@vazub Thanks for the reply.
I understand, and my point is that there was something wrong in v0.2.0, which has already been fixed now.
I tried ldd on lots of statically linked programs; some were written in C or Rust and linked with musl, while others were written in Go. ldd always reported "statically linked" without error. This also applies to coreutils-v0.2.2...
@sylvestre yes, verified.
Thanks folks @Ecordonnier added a test to make sure we don't regress in the future