Add support for alternative C libraries

[brson]

Makes snapshots more compatible. Required for microcontroller Rust. musl is the favorite.

[vi]

Vote up. I don't want musl-gcc (or similar things) to be the sole way to create little system stand-alone executables. I hope it will mix well with https://github.com/pcwalton/zero.rs

[thestinger]

We can eventually avoid the libc dependency completely in runtime-less Rust. It's not very hard to do system calls natively on x86 (interrupts) and x86_64 (syscall instruction). We would also need to support using the vdso to avoid unnecessary overhead on operations like checking the time, because those are optimized to read kernel-space memory without a context-switch.

[vi]

Mixed "little C library + little Rust runtime" can also be helpful, for projects using both C and Rust code.

Ideally it should be flexible: the more features you use, the more runtime and dependencies the program have.

[catamorphism]

Visiting for bug triage. Not a release blocker IMO.

[emberian]

Triage. Easy to do with #[no_std], I don't think it should be a priority atm.

[thestinger]

#2124 would make this very easy. In fact, it will probably just work out-of-the-box with most alternative C libraries if we did that.

[alexchandel]

Rust currently depends on gcc_s for task unwinding on linux and bsd. Dropping this dependency is necessary for systems without glibc/gcc.

[vi]

Is task unwinding only for debugging and/or error handling, or it is needed for any Rust code to run?

[alexchandel]

@vi Task unwinding is only for handling panics in the calling task. It is debatable whether this is even the correct behavior.

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#625