Project with bootloader v0.11; Error while compiling kernel, says std is required by serde

[Momijiichigo]

I also wrote the details of this problem in this GitHub issue comment:
rust-lang/cargo#11772 (comment)

Error

The compiler throws error while compiling kernel, saying a dependency serde uses std while kernel is no_std:

> cargo run
   Compiling serde v1.0.188
error[E0463]: can't find crate for `std`
  |
  = note: the `x86_64-unknown-none` target may not support the standard library
  = note: `std` is required by `serde` because it does not declare `#![no_std]`
  = help: consider building the standard library from source with `cargo build -Zbuild-std`

error[E0463]: can't find crate for `std`
   --> /home/daichi/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.188/src/lib.rs:166:17
    |
166 |         pub use std::*;
    |                 ^^^ can't find crate

Info

• kernel is no_std bindep artifact dependency, targeting x86_64-unknown-none
• The error happened when I added the dependency bootloader-x86_64-common,
  • the procedure here in the edition 3 draft
• When I move out the kernel folder and compile it as a separate single project (not as a bindep workspace member), it compiled successfully.

Steps to reproduce error

1. clone this repo: https://github.com/Momijiichigo/my-os/tree/cb1373ae72b3ec70a4fcd054e7c90ae6a29ffb19
2. cargo build

Comment

I don't know if this is a problem with cargo, but I posted this issue here just in case so that hopefully anyone here might be familiar with this problem and have solutions

[bjorn3]

Blog os required bootloader 0.9. It doesn't work with any later version of the bootloader crate as these rework the way building disk images is done.

[fooooooooooooooo]

Blog os required bootloader 0.9. It doesn't work with any later version of the bootloader crate as these rework the way building disk images is done.

they are following the draft of edition 3 which uses 0.11

[bjorn3]

I see. I think this is a cargo bug in the bin deps feature. I would guess it unified features between the kernel itself and the crate that builds the disk image.

[kastermester]

For what it is worth, I have also been toying around with something akin to what is in the edition 3 branch. Here's my rust-toolchain.toml file from the root of my workspace. (Note: I'm on an arm macbook, as such I cannot remember if the target also needs to be specified here or not):

[toolchain]
channel = "nightly-2023-04-03"
components = ["rust-src", "llvm-tools-preview", "rustfmt", "clippy"]
targets = ["x86_64-unknown-none"]

I suspect the part that is really worth sticking onto is the nightly version.

EDIT: Also my Cargo.toml workspace file is using package.resolver = "2".

[Momijiichigo]

@kastermester Thank you so much!!!
Adding resolver = "2" in the Cargo.toml solved the problem!! I never thought about that!!

[torrancew]

@Momijiichigo I would also recommend adding a kernel/.cargo/config.toml and specifying the following, to make everything a bit easier to reproduce:

[unstable]
build-std = ["core", "compiler_builtins"]

[build]
target = "x86_64-unknown-none"

It's also worth considering pinning a specific nightly version in your toolchain file, and specifying your targets:

[toolchain]
channel = "nightly-2023-09-04"
components = ["rust-src", "llvm-tools-preview"]
targets = ["x86_64-unknown-none"]

Both of these make it a bit more reliable for others cloning your repo to reproduce your environment.

[Momijiichigo]

@torrancew thanks for the advice!
Now I'm closing this issue since it's resolved

[phil-opp]

As an alternative to resolver = "2", you can also set edition = "2021" where the new resolver is the default. You already set the edition for your sub-crates, but not for the root crate.