"It's dead, Jim".png
This project has been inactive since 2017-10-20.
If you are interested in hassle-free cross compilation from any OS to Linux I would suggest looking into the Linux/MUSL targets:
$ cargo new --bin hello && cd hello
$ rustup target add x86_64-unknown-linux-musl
$ cargo rustc --target x86_64-unknown-linux-musl -- -C linker=rust-lld
$ file target/x86_64-unknown-linux-musl/debug/hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, with debug_info, not strippedIf you are interested in a Rust standard library free of C dependencies for Linux then I would suggest registering your interested in rust-lang/rfcs#2610
If you are interested in taking over the development of this project send me an e-mail (see my GH profile) and I'll transfer it and its dependencies to you.
-- @japaric, 2018-12-09
[WIP] Rust's standard library, free of C dependencies, for Linux systems
It's very early days. Very little functionality has been ported over.
The ultimate goal is achieve truly hassle free cross compilation from any system (macOS, Windows, *BSD, etc.) to any Linux system, be it x86 or ARM hardware. That is:
$ cargo build --target aarch64-unknown-linux-steed
Should work without having to install a C toolchain or cross compiled C libraries, and without having to run the command inside a Docker container / VM.
By removing all the C dependencies, steed solves half of the problem. The
other half will be solved by embedding lld, LLVM's multi-arch linker, into
rustc.
The short term goal is to provide the exact same functionality and API as the
std crate. Hopefully, by the time that's complete, PAL and std-aware Cargo
will be around and we'll be able to plug a pal_steed crate into the normal
std to get C free Rust programs.
Although, IMO, it would make more sense (*) and it would be more ergonomic to
land chunks of steed in rust-lang/rust and add a new set of built-in target,
e.g. aarch64-linux. That way, compiling C free Rust programs would be as
simple as e.g. cargo build --target aarch64-linux.
(*) Because linking requires different linker arguments and programs are always statically linked.
- Supporting other unix like systems, like the *BSD ones. Mainly because we have
no (easy) way to test them inside Travis and also to reduce the amount of work
required. After we are done with the C free port of
stdfor Linux then we can start thinking about supporting other OSes.
-
Zero C code. Zero C dependencies. Not even startup objects are required to link a
steedbinary.steedprograms should still be able to interoperate with or link to C code though (This last part is currently untested). -
Small, statically linked binaries:
// examples/hello.rs
use std::{io, process};
use std::io::Write;
fn main() {
if io::stdout().write_all(b"Hello, world!\n").is_err() {
process::exit(1)
}
}# xargo rustc --target x86_64-unknown-linux-steed --release --example hello -- -C lto
$ ./hello
Hello, world!
$ strip -s hello
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped, with debug_info
$ size hello
text data bss dec hex filename
173 0 0 173 ad hello
$ ls -l hello
-rwxr-xr-x 2 japaric japaric 4712 Apr 11 00:00 hello
Disclaimer The binary size will inevitably go up after we add missing startup/runtime features like stack overflow protection and unwinding.
Turns out that writing architecture specific code is tricky! We were trying to
provide "if it compiles, it works" level of support for every architecture that
std supports but that stalled development as it's hard to get some features
working on a bunch of different architectures.
So, we have adopted Rust's tier system to unstuck development. Our platform support is split in two tiers:
"If it compiles, it works" level of support. PRs won't land if CI tests don't pass on these platforms:
-
aarch64-unknown-linux-steed -
arm-unknown-linux-steedeabi -
armv7-unknown-linux-steedeabihf -
i686-unknown-linux-steed -
x86_64-unknown-linux-steed