0.2.0 prebuilt musl binaries are not statically linked

[vazub]

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.

[yangyingchao]

Something is wrong...

$ ldd coreutils
./coreutils: error while loading shared libraries: /lib64/libc.so: invalid ELF header

[zdiff]

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

[sylvestre]

@Ecordonnier ^^

note: this is why we should have a CI for this

[Ecordonnier]

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

[sylvestre]

we could disable libstdbuf for this platform

[yangyingchao]

+1 for disable libstdbuf.

[Ecordonnier]

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.

[yangyingchao]

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.

[vazub]

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.

[sylvestre]

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 :)

[vazub]

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.

[sylvestre]

It is a bug... if we had known, we would have communicated on this ... (and fix it)