Consider adding Linux targets that don't depend on libc

e.g. x86_64-linux (or x86_64-unknown-linux-rust).

These would be the spiritual successor of steed: a standard library, free of C dependencies, for Linux systems. Steed implemented (or planned to) the Rust standard library using raw Linux system calls instead of libc's API. These libc-less targets would also implement std using raw system calls.

Even though steed has been inactive for over a year people continue to star it on GitHub and currently has over 500 stars so it seems there's still interest for something like it.

What we learned during development is that maintaining a standard library out of tree is a lot of work because things get quickly out sync so if there's still interest for something like steed I would recommend writing an RFC to add support for libc-less targets (e.g. x86_64-linux) to rust-lang/rust; this would be equivalent to importing and developing steed as part of rust-lang/rust.

An RFC is also a good way to (re-)evaluate the ROI of making a libc-less standard library. One of the goals of steed was hassle-free cross compilation but today that's solved by the Linux/MUSL targets + rust-lld (works on stable). The other goal was better optimizations (plain LTO doesn't optimize across FFI) but cross-language LTO is a now thing (-Z cross-lang-lto). There may be less costly ways to achieve the same results.

The rest of this post describes the status of steed as of 2017-10-20 (date of last commit).

What we had working:

1. standard I/O (std::io::{stdin,stderr,stdout})
2. filesystem operations (std::fs)
3. collections (std::collections) (but see (a) below)
4. std::sync::Mutex (courtesy of parking_lot)
5. std::env
6. UDP and TCP sockets (std::net) (but see (d) below)
7. minimal support for threads and TLS
8. #[test] support (but see (c) below)

You can check the examples directory to get an idea of what you could write with it.

What was missing:

a. a proper allocator. steed used a bump pointer allocator that never freed memory
b. all the math stuff (e.g. f32::sin). These days one can use libm.
c. unwinding, all the steed targets used -C panic=abort
d. hostname lookup
e. errno. It was unclear whether we should implement it or not. It seems to only be required by std::io::Error::last_os_error. Linux system calls have a Result-like API so errno is not required to propagate errors from syscalls to the std API.

and much more stuff; you can check the issue tracker for the full list.

cc @tbu- @briansmith

Start by reading the proposal and its references to steed, the examples directory, and the steed issue tracker. Compare the stated libc-less target goals with Linux/MUSL targets, rust-lld, and cross-language LTO. Done would require an accepted RFC defining whether and how rust-lang/rust should support these targets.