Skip to content

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

New issue

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

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

Already on GitHub? Sign in 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.

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

No branches or pull requests

2 participants