Provide statically linked binaries with musl for linux

[jirutka]

Binaries for *-linux-gnu works only on glibc-based systems and nowhere else. When you link it statically with musl libc, then it will work on every Linux, regardless of which libc library it uses (musl, uClibc, glibc, …).

@japaric has already added support for musl in #2532.

I’ve successfully built cargo using cargo-bootstrap (well, with many ad-hoc workarounds because of cargo-bootstrap flaws) on Alpine Linux that is based on musl libc, the only problem is #2937 (my workaround.patch). However, I’ve linked it only dynamically, because of issue with rustc on musl.

[alexcrichton]

I'd love to do this! It should be quite easy to just cross-compile to musl, we just need to take care of rust-lang-deprecated/rust-buildbot#96. This basically will just require buildbot shenanigans.

[joshtriplett]

When adding support for this, please do not disregard the ability to statically link with glibc. Yes, it isn't a completely self-contained static link if you reference NSS, but it's still useful.

[jirutka]

Why would like to statically link with glibc? That doesn't make much sense for me.

[joshtriplett]

Any number of reasons. For instance, when shipping a program that actually wants to resolve names and respect any configured NSS modules; a binary linked to musl will fail to do so. Or, when shipping a program that needs to work with any resolv.conf file, including those musl's limited resolv.conf handling doesn't like. Or, when statically linking to a C library that depends on glibc.

[jirutka]

Well, that makes sense. However, the result binary will be probably very big.

[joshtriplett]

Potentially, though static linking allows discarding unused parts of the library.

In any case, I just wanted to make sure that no assumptions like "static linking always uses musl" got hardcoded.

[jirutka]

I just wanted to make sure that no assumptions like "static linking always uses musl" got hardcoded.

Totally agree, this decision that musl equals static linking was very wrong and it made porting rustc to Alpine Linux much harder.

[jirutka]

Potentially, though static linking allows discarding unused parts of the library.

That’s actually interesting question – does rustc currently discard unused code?

[japaric]

That’s actually interesting question – does rustc currently discard unused code?

That would be mainly the linker's job since it's about eliminating glibc's code rather than rustc generated code.

[aidanhs]

Statically linking glibc isn't something that rust itself really supports right now. It's possible (I was doing it pre-musl) but it requires hacking around with the arguments rustc passes to the system linker - I'm not sure the cargo build process is the right place to start talking about it, there's likely a large number of assumptions already in rustc itself!

FWIW, I'm vaguely in favour of the ability to statically link glibc, but I'm pretty sure it's a bad idea to distribute static binaries which try to use NSS (like Cargo) - if you compile a C program like this it will tell you that you need the same version of glibc at runtime as you had at compile time. This is because have the static libc in your binary and you have the dynamic libc linked to NSS modules which could create interesting problems like the two libcs

• clobbering the heap because they don't understand how to cooperate with each other
• causing segfaults because you're implicitly relying on private details of libc that were never intended to be stable, like the layout of FILE, by passing data between them

I'd be interested to hear of statically linked binaries being distributed and using NSS on target machines successfully. I'm not sure how you could do that reliably?

[joshtriplett]

Honestly, I'd be just as happy with a program that statically links everything except glibc, dynamically linking libc.so.6 and nothing else.

[zoumi]

Does Cargo surpport --dynamic-linker option?

http://stackoverflow.com/questions/847179/multiple-glibc-libraries-on-a-single-host/851229#851229

[alexcrichton]

Done!

[jirutka]

Thanks a lot, but why it’s not available in https://static.rust-lang.org/cargo-dist/ as nightly builds for other platforms?

[alexcrichton]

Binaries are uploaded to a new location now, such as https://s3.amazonaws.com/rust-lang-ci/cargo-builds/c96d76036d615330e3ba853c6fb32fcd92752ca8/cargo-nightly-x86_64-unknown-linux-musl.tar.gz

[jirutka]

Then you’ve forgotten to update URIs in the README.