Make it possible to statically link system libraries

The major use cases:

• unified snapshots for Linux: {i686,x86_64}-unknown-linux-{gnu,uclibc(,newlib?)} and x86_64-unknown-linux-gnux32 can all run on the same 64-bit kernel. This would make eventual porting easier.
• rescue/bootstrap utilities that don't depend on the host environment
• whole-program LTO where possible
• embedded
• single-executable Windows binaries that need no installer (see also: include! and gcc/MinGW's -static-libgcc flag)

[alexcrichton]

This is possible via the #[link(name = "foo", kind = "static")] link directive (documented here). Has that been found to be insufficient?

So far I've found no way to link libc statically. I've tried:

#[link(name="test", kind = "static")];
#[crate_type="bin"];
#[link(name="c", kind="static")]
extern {}

fn main () {}

• rustc -Z prefer-static: unknown debug flag
• rustc --link-args -static: linker errors (multiple definition and others)
• rustc --link-args -static-libgcc: does compile, but libgcc_s.so.1 shows up in ldd all the same.

The runtime seems to pull in dynamic libraries unconditionally.

[alexcrichton]

Right now, rust's libstd requires various system libraries in order to function. This currently includes dl, rt, m, and stdc++. It is not possible to produce a totally standalone executable today with 0 dependencies of the system that it is running on.

In the crate you've listed, #[link(name = "test", kind = "static")] has no effect on the output (other than naming the binary test). When you declare #[link(name = "c", kind = "static")], then when producing a binary this just means that rustc will pass -lc to the linker.

It sounds like you're trying to produce a statically linked executable while using libstd, which today is not possible. I want to be able to drop dynamic dependencies which you aren't using, but today that's not implemented. For now though, I'm going to close this because everything is working as intended.

Rust supports static linking to the fullest extent that it is currently possible. I doubt that we will soon reach a point at which the compiler can generate a truly standalone executable when linking to libstd, but the compiler is more than capable of generating a fully standalone executable with rust library dependencies if nothing uses libstd. It may be a bug that libstd has so many dynamic dependencies, but they're going to be tough to remove (although we should attempt to pursue them if reasonable).