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

Momijiichigo commented 10 months ago

I also wrote the details of this problem in this GitHub issue comment: https://github.com/rust-lang/cargo/issues/11772#issuecomment-1705900313

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

clone this repo: https://github.com/Momijiichigo/my-os/tree/cb1373ae72b3ec70a4fcd054e7c90ae6a29ffb19
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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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

torrancew commented 10 months ago

@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 commented 10 months ago

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

phil-opp commented 10 months ago

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.

phil-opp / blog_os