Standard library support for x86_64-unknown-linux-none

[binarycat]

currently this target has the absolute lowest support level, tier 3 with no standard library support or host tools.

it seems like it shouldn't be too hard to bump this up at least one level to "limited standard library support". this could allow some applications the ability to be built with no libc without requiring a full rewrite. there would be a few limitations, such as probably forcing panic=abort, and probably most limitingly: no std::thread.

i think the most important module would be the unix filesystem layer.

ironically, it should actually be fine to keep the dependancy on the libc crate, since it defines a lot of constants used in linux syscalls. if it tries to actually pull in code from libc, it should hopefully result in link-time errors saying what function is trying to call into libc.

[programmerjake]

it looks like the libc crate tells the compiler to link the c library by default: libc/src/unix/mod.rs at acc7bb1a38e2b9d6a18f28279d80d464c4c25089 · rust-lang/libc · GitHub

so, you'll probably need to change that if you want to end up with no libc.

[Vorpal]

There are alternatives to using libc, though I think they need nightly. GitHub - sunfishcode/eyra: Rust programs written entirely in Rust comes to mind, though I think there are a few related efforts.

[bjorn3]

The linux-raw-sys crate defines all these constants and such too. Rustix uses it for direct linux syscalls without going through libc.

[chrisd]

I think we have a lot of assumptions that Unix == libc. Or perhaps more accurately Unix == POSIX + system specific APIs. Untangling that may be more work than it appears.

[binarycat]

yeah, getting the full standard library to work would obviously be a major undertaking.. but i think at least getting the io module to work shouldn't be too hard.