@japaric: Real hardware. Most targets would be best with OpenBSD since it supports just about everything, but that's going to complicate things a bit.
I'll see what modern Linux I can get running on my old PPC Mac and move on to the next target from there.
QEMU-based infrastructure is likely the best way to go, maintainablity-wise. Is there a script you're using for that? Did you cook one up for yourself?
I think it would be interesting to see an OpenBSD or similar BSD branch of the project. If nothing else, we'd get a sense of how much would be similar and how much would be different. It might then lead to a way to merge the BSD work into the Linux work in the best way. The sooner that input is available, the sooner the Linux side could make abstractions and adjustments to make multi-OS support better.
@RandomInsano There's no BSD support right now because we have no infrastructure to test that. Some chunks of steed may work on BSD because POSIX but we can't guarantee there'll be no BSD regressions. Also, the sc crate we are using right now to do syscalls only supports x86_64 FreeBSD (as BSDs go).
QEMU-based infrastructure is likely the best way to go, maintainablity-wise. Is there a script you're using for that? Did you cook one up for yourself?
I'm using cross, a thing I cooked up myself 
.
Dude! That's awesome! I'll have to start playing around with cross!
I got Debian on my old flower power iMac G3 with rustup last night and it's working great. As long as the compile fits in 256MB of RAM we'll be in a good spot. 
I have a mini-farm of CHIPs for armv7hf so that's good to go too. I threw out my SPARC hardware awhile ago, but I know some guys.
Update: LLVM seems to be missing support for SPARC. Not gunna happen! 
Where did you get that impression?
It says right on the LLVM "Features" page that the code generator supports SPARC and, according to this StackOverflow answer, Clang 3.3 supports sparc and sparcv9, which would be difficult to do if LLVM didn't. According to the code generator feature matrix, "Sparc" "is generally reliable" and has disassembler support, which MIPS doesn't, and Rust works on MIPS.
More significantly, pull requests have been merged for very initial sparc and sparc64 support in Rust. (And the former mentions a sparcel target that LLVM apparently also supports.)
Looks like my source is 7 months outta date:
https://www.google.ca/amp/s/amp.reddit.com/r/rust/comments/4n3awg/no_rust_for_solaris_sparc_and_aix_power/
Since I started learning Rust a few months back I was wondering why compiled rust apps depend on libc. Just found this thread and @japaric thank you for working on steed. Hopefully something like this end up in upstream.
A few random thoughts. This library abstracts platform-specific code. Something that provides unified interface for underlying OS interface (maybe it should be called libplatform rather than libstd?). And while making it Linux-only is a great first step, in the future such library needs to work on any platform supported by Rust:
syscall interface, as said it is ABI compatible and fine to depend on it from an app.bionic than in glibc.libSystem. This is the lowest available application interface.libplatform for its platform. It automatically makes Rust applications compatible with such OS.A silly question here 
I am new in rust, so please don't mind if I go wrong.
In steed, every syscalls are called through syscall crate and internally every calls are done using asm! macro (or by assembly language).
I want to know that how to do this same in Windows? Is that possible to make system calls in windows like we are doing in Linux by assembly language(in other words, by syscall crate/asm! macro)? If not, is there any examples to do that?
Thanks!
On Linux, you can do it because the kernel team guarantees that new versions will only add new syscalls, not change existing ones.
On Windows (and MacOS), you have to call an abstraction library they provide because they reserve the right to change how the raw syscalls work as new versions come out.