You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just noticed that x86_64-unknown-linux-musl is tier 2 and the only thing verified is that the standard library compiles. Since most (?) CLI apps for linux are compiled with musl, I wonder if it should be given a higher priority given it's relative usage https://forge.rust-lang.org/platform-support.html
Especially since Rust requires a very recent libc to run, it's the only way to get Rust to run on slightly older (but still very common) platforms like Debian Wheezy
From burntsushi
using musl is a very simple way to produce an executable with zero dynamic dependencies (ldd rg on the MUSL release binary should say "not a dynamic executable"). it is not always possible. for example, if your binary needs to talk over https, then you probably need to ship a binary that links to the native SSL implementation on your platform. this is likely why cargo and rustup don't ship musl binaries (perhaps among other things).
The text was updated successfully, but these errors were encountered:
Linking Linux binaries against the glibc targets i686-unknown-linux-gnu and x86_64-unknown-linux-gnu will not produce static binaries since it dynamically links against the systems glibc and possibly others (e.g. OpenSSL).
Since binaries produced in CI should work without depending of specific versions of libraries being installed in the users system, I think it is better to link the released binaries against the musl targets (i686-unknown-linux-musl and x86_64-unknown-linux-musl).
While you might have to use helper crates like openssl-probe to make some things work, I prefer truly portable binaries over the alternative.
From rcoh
From burntsushi
The text was updated successfully, but these errors were encountered: