Create a musl build

[aidanhs]

This issue is to track my desire to have a nightly musl build.

We can't use a release of llvm because 3.7 isn't out yet (https://llvm.org/bugs/show_bug.cgi?id=23364), so I'd say there's nothing to do at the moment.

[Gankro]

3.7 is out

[aidanhs]

I've updated the instructions - rust-lang/rust#28389
Much friendlier than SVN checkouts.

[saeta]

@aidanhs any updates to the status of this? Is this something that can be done?

[jimmycuadra]

/cc @alexcrichton, I know he was working on musl support and may have some info on the status of this.

[aidanhs]

There was a recent thread on this on rust-internals - https://internals.rust-lang.org/t/request-for-adding-free-hardened-bsd-and-linux-musl-to-official-releases/3185

I think the crucial quote is this:

For a MUSL compiler we currently infer that "MUSL == statically linked", which primarily means that operations like dlopen will not work. This is currently how compiler plugins are implemented, so the MUSL nightly compiler would not be as full featured as the other nightly compilers, and we don't currently really support compilers that have half the features of others without a path to earning them.

Which I believe roughly translates to: "MUSL doesn't do dynamic builds. Dynamic builds are required for some nightly features and we don't want crippled nightly builds, so MUSL will not become a nightly build."

I think the next step is to do one of two things:

1. Convince the rust team that they should do stable releases of MUSL even though there aren't nightlies. Probably a tough sell!
2. Figure out some way to make compiler plugins work in musl. Here's some useful info on dlopen and static linking if anyone's interested - http://www.openwall.com/lists/musl/2012/12/08/4. Sounds decidedly nontrivial.

As I've mentioned in the topic, adding the ability to dynamically link MUSL binaries will probably not help - it's effectively a different target to static musl, so you'd just end up with nightly releases of dynamic musl :(

[saeta]

Perhaps I'm missing something, but @aidanhs is it not possible to have a rustc that itself uses dynamic linking (for complier plugins), but that can produce binaries that are statically linked?

[aidanhs]

Being brief because my last toying with the rust build system was a while ago: I think the last stage of the rust build system (stage3 iirc) is effectively "let's test if this compiler is self-hosting". So to answer your question: maybe, but this seems like it'd subvert the point of this final stage.

(but I may be totally wrong, as I seem to recall that a rustc compiler able to build musl must also be able to build glibc executables for some reason, which raises a question-mark over what I say. I'll delete my comment if it turns out I'm spreading bad information)

[saeta]

I just built from source a MUSL compiler and it does output glibc binaries unless you ask it to do MUSL.

root@fe0bc3707fc5:/src/example# rustc example.rs
root@fe0bc3707fc5:/src/example# ldd example
        linux-vdso.so.1 =>  (0x00007ffdf65fe000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4b4d0a8000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4b4ce8a000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4b4cc74000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4b4c8af000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4b4d4fe000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4b4c5a9000)
root@fe0bc3707fc5:/src/example# rustc --target=x86_64-unknown-linux-musl example.rs
root@fe0bc3707fc5:/src/example# ldd example
        not a dynamic executable

I'm currently building a docker container to contain the MUSL compiler, but it'd be nicer if I could just use a pre-built compiler.

[aidanhs]

@saeta as I find happens very often, @alexcrichton is a few steps ahead and already has dockerfiles for musl rust! https://github.com/alexcrichton/port-of-rust

Regarding the --target - yes, I remember that now. So this now comes full circle to the original point I think? Compiler plugins are necessary for a 'supported' compiler, so gnu has to be built in to be able to get a dynamically linked compiler (to get compiler plugins), hence static musl can't currently be a first class target by itself. Or something along those lines - I'll refrain from saying any more until there's an official comment.

[alexcrichton]

Oh right! I forgot to close out this issue :) So, the state of things today:

• We have a MUSL builder defined here
• We're gating on MUSL tests passing via the auto-linux-musl-64-opt builder.
• We're producing MUSL standard libraries each night

In terms of building a compiler linked against MUSL I'd definitely be up for at the very least supporting that! The first step would just be adding support to the build system to actually do that. Then there'd probably also be some changes to the builder image to for example get a libstdc++ linking against MUSL.

If we've got that up and running seems easy enough to add a new builder and a new nightly! (pretty low cost on our end)

Does that help @aidanhs and @saeta? I'm gonna close this issue specifically (as we have the nightly MUSL standard library), but feel free to open an issue in rust-lang/rust about enabling a MUSL compiler!

[aidanhs]

The new rustup now allows you to download the musl stdlib for use with your compiler, so no compilation needed. See https://internals.rust-lang.org/t/static-binary-support-in-rust/2011/53.