Static binary support in rust

[aidanhs]

Linking to glibc-static is neither impossible nor ill-advised nor unsupported, it just requires you to be aware of the subtleties of NSS. If you do not need NSS or you enable static NSS when compiling glibc, statically linking glibc is fine.

In the blog post you refer to, they link against a C program which does not need NSS so all is well. If they were to try and link statically against Python it could fail in mysterious ways inside a container.

Go gets away with this in general because linking to existing C libraries is not popular - reimplementing in pure go is much more common. And so because, as @steveklabnik says, the go runtime don’t use libc at all there’s no need to link against it. One obvious tradeoff is that go therefore doesn’t use NSS. Try and make the Docker socket be owned by an LDAP user - it won’t work, because go won’t use nsswitch.conf. I had to write a patch to allow specifying ids to work around this.

Coming back to Rust, I (and others) use musl and it works pretty well. Just follow the instructions in the nightly docs.

[jimmycuadra]

Thanks for the responses, they were very helpful!

I hadn’t discovered the advanced linking section in the book because I was looking at the stable docs which only talk about the link_args feature.

I opened an issue on rust-lang/rust about an official binary distribution of Rust with musl enabled, since the Rust 1.1.0 blog post suggested they were going to make one. Does anyone know if this is still planned or why it hasn’t happened yet? As far as I can tell, the only reason this documentation is included in the “Nightly Rust” section of the book is because you have to build the compiler yourself, not because it depends on any unstable features. I’d like to see a musl-enabled version of Rust on https://www.rust-lang.org/install.html as an alternative option for Linux because of its usefulness and to make it clear that Rust can do this! It’s a big language selling point, IMO.

[jimmycuadra]

Go does not use libc, they re-implemented all the funcationality themselves.

I found more information on why Rust didn’t do this (and probably won’t in the foreseeable future) from Erick in a Hacker News comment responding to the question of why Rust needs libc:

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.

Now there are some languages, namely Go, that skip libc and just implement directly against the syscall interface. Go has the advantage of being able to draw from Google’s vast experience interacting deep within the system, so it was comparatively cheap for them to do this.

For rust, it never really felt like it was worth the effort for the benefit we’d get out of it. It was more important to get the language done.

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.

[aidanhs]

IIRC the liblibc crate within rust was broken for musl in Rust 1.1, so musl builds for that version may be broken in surprising ways.

Builds seem to be planned, but I don’t know what the current priorities are. Though I’ve just discovered the buildbot configuration, so potentially all I need to do is make a PR there…

[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