I'm trying to port the std library to a custom OS. I found this guide on the net which I'm trying to follow.
The guide works quite well until you are supposed to compile the standard library. Then I get the following errors.
cargo build --target armv7a-unknown-myos-eabi -Zbinary-dep-depinfo --release --features "panic-unwind compiler-builtins-c compiler-builtins-mem" --manifest-path "library/test/Cargo.toml"
Compiling cc v1.0.76
Compiling core v0.0.0 (...\rust\library\core)
Compiling libc v0.2.138
Compiling std v0.0.0 (...\rust\library\std)
error: cannot find a built-in macro with name `derive_const`
--> library\core\src\macros\mod.rs:1465:5
|
1465 | / pub macro derive_const($item:item) {
1466 | | /* compiler built-in */
1467 | | }
| |_____^
error: cannot find a built-in macro with name `alloc_error_handler`
--> library\core\src\macros\mod.rs:1523:5
|
1523 | / pub macro alloc_error_handler($item:item) {
1524 | | /* compiler built-in */
1525 | | }
| |_____^
error: cannot find a built-in macro with name `type_ascribe`
--> library\core\src\macros\mod.rs:1557:5
|
1557 | / pub macro type_ascribe($expr:expr, $ty:ty) {
1558 | | /* compiler built-in */
1559 | | }
| |_____^
Compiling compiler_builtins v0.1.85
Compiling unwind v0.0.0 (...\rust\library\unwind)
error: attributes starting with `rustc` are reserved for use by the `rustc` compiler
--> library\core\src\ptr\metadata.rs:53:28
|
53 | #[cfg_attr(not(bootstrap), rustc_deny_explicit_impl)]
| ^^^^^^^^^^^^^^^^^^^^^^^^
Obviously it cannot find built in macros. I'm guessing here but one observation is that in the guide the standard library seems to be compiled to the same as the host CPU architecture (x86-64). In this case the built-in macros are already there. In my case I compile on an x86 but the target architecture is ARM. Do you need to do something extra with the compiler when you have new target CPU architecture or is just a library that needs to be compiled correctly?
Another observation that is not brought up in the guide is the actual extra code required in order to support a new OS. That might perhaps been omitted to limit the scope. However, when you have a new OS, I've seen that you have a library/std/src/sys/unsupported directory which essentially stubs for all the OS supports to be filled in. Are you supposed to be copying the unsupported directory to library/std/src/sys/myos, and the continue to "fill in the blanks" from there? Will the build system automatically use the "myos" directory based on the information from the target triple or target.json file?