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. [steed]: https://github.com/japaric/steed 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). W
Posted by japaric on Dec 9, 2018, 2:51 PM
Tags
Related issues
Raise real-world problems, find people facing the same issue, and discuss solutions.4,000 issues0 comments
support (Sysadmin)
Support connecting to remote devcontainers (devcontainer on remote host)
Option to use Waffle menu or links displayed normally
I also attempted to package ROCM on musl.
But why is there no such pushback agains linux kernel?
OpenCode Support
Upcoming changes to the tado° API
Allow Mac users to use Apple native containerization
Support for the Containerization Framework on macOS
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. [steed]: https://github.com/japaric/steed 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). W
Comments (0)
No comments yet. Start the discussion.