Skip to content

Any advice on feature unification when using bootloader in workspace #498

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
AaronJThompson opened this issue Mar 20, 2025 · 2 comments
Open

Comments

@AaronJThompson
Copy link

I've been following the guide on setting up the workspace such that the kernel is in a separate crate and is brought in as an artifact dependency:

[build-dependencies]
bootloader = "0.11.4"
kernel = { path = "kernel", artifact = "bin" }

[workspace]
resolver = "2"
members = ["kernel"]

The problem I'm having is that when I use the vga crate, which uses bitflags, it contains the std feature as bootloader also uses this crate in std env.

Leading to this error:

   Compiling kernel v0.0.0 (REDACTED)
error[E0152]: found duplicate lang item `panic_impl`
  --> kernel/src/main.rs:31:1
   |
31 | / pub fn panic(_info: &PanicInfo) -> ! {
32 | |     loop {}
33 | | }
   | |_^
   |
   = note: the lang item is first defined in crate `std` (which `bitflags` depends on)
   = note: first definition in `std` loaded from /home/aaron/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-d65a5ac20318153f.so, /home/aaron/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-d65a5ac20318153f.rlib
   = note: second definition in the local crate (`kernel`)

Is there any way to get around this? I was hoping artifact dependencies would be completely seperate but that doesn't seem to be the case. Am I doing something wrong in my setup?
I've tried explicit using bitflags with default-features=false and using the v2 resolver to no avail

@AaronJThompson
Copy link
Author

I should note that I'm setting target in kernel/.cargo/config.toml so I can use my own target settings and build-std options

@Freax13
Copy link
Member

Freax13 commented Mar 22, 2025

Try moving the kernel into a separate workspace. You can exclude it from your main workspace by setting workspace.exclude.

Out of curiosity: Can you reproduce this issue using the latest nightly compiler? I know that we've also had this problem recently and solved it by moving our test kernels to a different workspace, but for some reason, I can't reproduce the issue right now.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants