Static binary support in rust

[jimmycuadra]

There already seems to be a musl build but I’m not sure if this is directly related to what gets added to https://static.rust-lang.org/dist/, and certainly it’s not related to the main download options shown on https://www.rust-lang.org/install.html.

[steveklabnik]

I saw a comment from Steve on HN saying effectively the same thing when I was Googling around earlier, but now I can’t find it.

It’s also just things like bugfixes, too. Just like any other project, you can write it yourself, or you can use a dependency. Pros and cons to both.

I will also say (this might have been mentioned above, sorry if I’m repeating) that in Go, lots of people build everything in go, which means interop with C stuff is much lower priority. Us having good interop with C and C libraries is very important, and lots of them are built on libc. This affects other things too, like threading models.

[retep998]

[quote=“jimmycuadra, post:37, topic:2011”][quote] No it’s not a stupid question. libc (or CRT on windows) really is the library that exposes all the user space system libraries. It contains the functions to do IO, sockets, threads, and etc. So we use it to expose that functionality to rust users. [/quote][/quote] Just clarifying that the CRT on Windows is not the library that exposes the user space system libraries. Windows provides its own set of DLLs that provide all the system stuff and the CRT is just a layer on top to provide the C standard library which Rust only uses for math functions, the entry point, and a few memory functions like memcpy.

[gkoz]

My use case is creating Docker images that contain only static binaries with no operating system, like this:

FROM scratch
COPY ./rust_program /rust_program
CMD ["/rust_program"]

where rust_program is just a binary that was compiled on any system with a Linux kernel

Is the desire to put exactly one file into the container really worth the trouble? Isn’t producing one self-sufficient file, like, the container’s core competency?

[jimmycuadra]

My use case is creating Docker images that contain only static binaries with no operating system, like this:

FROM scratch
COPY ./rust_program /rust_program
CMD ["/rust_program"]

where rust_program is just a binary that was compiled on any system with a Linux kernel

Is the desire to put exactly one file into the container really worth the trouble? Isn’t producing one self-sufficient file, like, the container’s core competency?

It’s an approach that effectively uses the container as a packaging format, along with the runtime isolation and resource constraints offered by namespaces and cgroups that you wouldn’t get if you were executing the binary directly on the host machine. It’s the primary application deployment strategy for projects like CoreOS and Kubernetes. Everything is in a container and all the orchestration tools are built around manipulating containers and scheduling them across a cluster. I use a different Docker image to actually build the program and produce the binary. This means that the runtime container is much smaller because it doesn’t contain an OS and all the build tools. The space savings between the two is quite significant when you start to have lots of applications in your cluster.

[gkoz]

You’re talking space savings compared to putting the actually used dynamic libraries in there and nothing else, right?

[jimmycuadra]

You’re talking space savings compared to putting the actually used dynamic libraries in there and nothing else, right?

That’s actually not something I’ve seen commonly in the Docker ecosystem today. Most of the time people are just using a slimmed down OS image (commonly Debian) as the base. Technically unnecessary, done either out of convenience for simplifying the build process or pure ignorance. This silliness aside, I still think it’s very worthwhile to pursue static binaries in Rust.

[jimmycuadra]

I’m bumping this again in the hopes of getting the attention of whomever has control of the build and release process for Rust. I’d really like to see a musl-targeting rustc binary for Linux as one of the install options on https://www.rust-lang.org/install.html. (Discussion moved from https://github.com/rust-lang/rust/issues/27933 per Steve’s request.)

[steveklabnik]

/cc @alexcrichton

[aidanhs]

You’re waiting for this issue I think - now llvm 3.7 has been released there’s no need to engage in svn checkout madness, musl rust can theoretically be set up as a first-class target on the buildbots. It’s also now even easier to build your own!

Unfortunately the rust buildbots are not fully documented so it’s a little tricky if you were to want to help - I understand it’s on a todo list.

[alexcrichton]

Don’t worry, we haven’t forgotten about this! We’re still working on getting the infrastructure in shape to get to the point where we can easily ship new targets and you can install them super easily as well.

In the meantime, though, you can either build MUSL from source (instructions) or I’ve also started playing around with Docker a lot recently and I’ve created a bunch of images which should have things like MUSL or Android installed and ready to go by default:

alexcrichton/port-of-rust

[aidanhs]

In the meantime, though, you can either build MUSL from source (instructions) […]

Onlookers: if you want to do it manually (rather than use the dockerfiles) I wouldn’t look at the stable docs for now - nightly docs have been updated for llvm 3.7, which doesn’t need svn checkouts, per my previous message.

[mzabaluev]

I’m not very advanced in containers, but I thought they are ideal for just the opposite: requesting exactly the dynamic libraries your application wants to use, and having them baked into the container filesystem, isolated from the libraries of the host system. If done right, you can even get the read-only pages of library images shared in memory across containers, rather than replicating the entire userland stack linked into each application binary over and over, trashing the CPU caches with redundant copies of frequently used code.

[m4b]

Mrello, first time posting here, hello! Sorry if I’m necro-bumping but I’ve been waiting for essentially the --target=x86_64-unknown-linux-musl in the regular nightly with bated breath for sometime now, so I don’t have to build my own rust compiler from source, from time to time.

I’ve noticed that this aforementioned issue has been closed almost a month ago.

Is there any hope of this entering into nightly (or stable even)?

Thanks so much

[alexcrichton]

It is indeed available now! You can install a MUSL + Rust standard library with our cross standard support and then it should be as simple as cargo build --target x86_64-unknown-linux-musl!

[m4b]

There aren’t enough emoji to give you right now

[m4b]

Hello again, so I’ve almost switched my custom toolchain over completely to the new rustup.sh setup (which is amazing btw), but I’m having one last issue.

So the first thing that I noticed was that a static libc is gone, as you might use in https://doc.rust-lang.org/book/advanced-linking.html

Correct me if I’m wrong, but it looks like you have replaced libc.a, pthreads and libm with liblibc-<rusthash>.rlib (this is a great move w.r.t. static linking).

Second thing is that I’m using an unusually complicated link sequence, which is essentially:

1. first compile rust code with musl equipped rustc and output an object file
2. link this object file and pass in special flags, and create a final Position Independent Executable. This last flag is -pie for ld

So, I’ve noticed that when using -pie with the new system, and custom linking against the liblibc wrapper, I get relocation errors related to -fPIC.

Here is a script which illustrates this point:

#!/bin/bash

# assumes you have run `rustup.sh --channel=nightly --with-target=x86_64-unknown-linux-musl`

SONAME=derp.so.1
RUSTLIB=/usr/local/lib/rustlib/x86_64-unknown-linux-musl/lib
RUSTHASH=$(ls $RUSTLIB/ | grep libstd | grep -oe "-[[:alnum:]]*" | grep -oe "[[:alnum:]]*") # yup you can make fun of me it's cool
DERP=derp

cd /tmp
rm $DERP.rs 2&> /dev/null

cat <<$DERP >> $DERP.rs
#![no_main]
pub extern fn deadbeef (){
  let deadbeef: u64 = 0xdeadbeef;
  println!("{:x}", deadbeef)
}
$DERP

rustc --target=x86_64-unknown-linux-musl $DERP.rs -g --emit obj -o $DERP.o

# -pie causes link errors like:
# ld: /usr/local/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-18402db3.rlib(sysconf.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
# /usr/local/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-18402db3.rlib: error adding symbols: Bad value

ld --gc-sections -soname $SONAME -pie -o $SONAME $DERP.o "$RUSTLIB/libstd-$RUSTHASH.rlib" "$RUSTLIB/libcore-$RUSTHASH.rlib" "$RUSTLIB/librand-$RUSTHASH.rlib" "$RUSTLIB/liballoc-$RUSTHASH.rlib" "$RUSTLIB/libcollections-$RUSTHASH.rlib" "$RUSTLIB/librustc_unicode-$RUSTHASH.rlib" "$RUSTLIB/liballoc_system-$RUSTHASH.rlib" "$RUSTLIB/libcompiler-rt.a" "$RUSTLIB/liblibc-$RUSTHASH.rlib"

if you remove the -pie option, it links correctly, and you receive a ET_EXEC; but I need a ET_DYN for a PIE…

[alexcrichton]

Yeah we’ve actually just slurped up the MUSL libc.a and shoved it into liblibc, so that contains just the raw object files of the MUSL distribution.

The error you’re seeing does seems kinda weird? I wonder if we’re not compiling with -fPIC? Although I thought MUSL did that by default… You can see how we’re compiling MUSL here

[m4b]

MUSL should be compiled with -fPIC.

I have noticed that:

rustc --target=x86_64-unknown-linux-musl -C relocation-model=pic yields a ET_EXEC,

but rustc --target-x86_64-unknown-linux-gnu -C relocation-model=pic yields a ET_DYN (a PIE).

It might seem a little strange to be asking to create a completely static executable which is also a PIE, but to give context to my linking requirements, a dynamic linker needs to be a shared object (since it exports dlopen, etc), and is loaded at arbitrary memory addresses by the kernel and execute starting from e_entry, which is the requirements for a PIE.

Here is the actual script I currently use to create the dynamic linker: https://github.com/m4b/dryad/blob/master/static.sh

Actually everything can be replaced with the new rustc system, except the final call to the libc.a, which baffles me since liblibc.rlib should just wrap the libc object that is generated…

[alexcrichton]

Yeah unfortunately things like ET_EXEC and ET_DYN are beyond what I know, so I may not be of much help