It has also become easier than ever to cross-compile for Redox, with the redoxer tool which can build, run, and test using commands similar to cargo. It automatically manages a Redox toolchain and can run executables and tests for Redox inside of a container on demand.
However, a long-standing issue (the longstanding issue?) of Redox OS has been this: To allow the compilation of Rust binaries on Redox OS.
Attempts have been made in the past to address this issue. In 2017, Redox OS participated in the Google Summer of Code. Through the excellent work done by ids1024, Redox OS was able to get close to self-hosting. This work was then amplified by the creation of a C library written in Rust, relibc. Subsequent work by over 40 contributors has led to significant POSIX C library compatibility, and a significant increase in the number of available packages.
Work was later done to convert Redox OS to a different Rust target family, finally unifying Rust support for Redox OS with that of other Unixen. Finally, Redox specific support code could largely be eliminated from codebases. This led to a great number of Rust crates suddenly gaining Redox OS support.
It seemed that as though the dream of self-hosting would soon be reality. After many heartbreaking hours (days, weeks, months?) of compiling rustc, then finding some error requiring more work in relibc, I was finally able to compile a statically linked rustc – only to discover that rustc is no longer capable of running statically linked!
Then began work on relibc’s ld.so, which provides dynamic linking support for executables. Tragically, the work to support dynamic linkage in Rust for Redox OS defaulted everything to dynamic linkage, which took some time to sort out properly. This is where work was halted on porting rustc to Redox OS.
Building Redox OS on Redox OS has always been one of the highest priorities of the project. Rustc seems to be only a few months of work away, after which I can begin to improve the system while running on it permanently, at least on one machine. With Redox OS being a microkernel, it is possible that even the driver level could be recompiled and respawned without downtime, making it incredibly fast to develop for. With this in place, I would work more efficiently on porting more software and tackling more hardware support issues, such as filling in the USB stack and adding graphics drivers.
But, more importantly than what I will be able to do, is the contributions by others that will be unlocked by having a fully self-hosted, microkernel Operating System written in Rust, Redox OS.