Repository navigation
Add support for alternative C libraries #7283
Description
Activity
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.rsWe can eventually avoid the
libcdependency 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 thevdsoto avoid unnecessary overhead on operations like checking the time, because those are optimized to read kernel-space memory without a context-switch.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.
Visiting for bug triage. Not a release blocker IMO.
Triage. Easy to do with
#[no_std], I don't think it should be a priority atm.#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.
Rust currently depends on
gcc_sfor task unwinding on linux and bsd. Dropping this dependency is necessary for systems without glibc/gcc.Is task unwinding only for debugging and/or error handling, or it is needed for any Rust code to run?
@vi Task unwinding is only for handling panics in the calling task. It is debatable whether this is even the correct behavior.
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
- added a commit that references this issue
on Jun 3, 2021
Makes snapshots more compatible. Required for microcontroller Rust. musl is the favorite.