Stack trace for duplicate lang item?

[illuzen]

I am building my project with -Z build-std and I get

error[E0152]: duplicate lang item in crate core: sized
|
= note: the lang item is first defined in crate core (which std depends on)
= note: first definition in core loaded from .../target/wasm32-unknown-unknown/debug/deps/libcore-1bda2c0fe1509098.rlib, .../target/wasm32-unknown-unknown/debug/deps/libcore-1bda2c0fe1509098.rmeta
= note: second definition in core loaded from.../.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libcore-ca9fe48a49de91a5.rlib

If I build with -Z build-std=std I get the same error. If I build with -Z build-std=std,panic_abort it compiles. I discovered this thru trial-and-error, and actually I need to it to build with just -Z build-std. The panic_abort field was not mentioned in the rust handbook, I had to discover it with AI, which got many things about this flag explicitly wrong.

I think it would be helpful if these conflicting definitions had more details showing exactly which dependencies called in each copy of the duplicate (core in this case). Basically I want a cargo tree like command that shows the ultimate origin of this collision.

Perhaps there is already a flag that does this? I have spent many hours on this, and have consequently learned a fair bit about rust internals.

Thank you for your time. Rust is amazing.

[ehuss]

This is probably pretty far outside of the scope of the project, as this would require deep changes in rustc to support. This error isn't supposed to happen, and we have #31 tracking as an approach to avoid it.

[illuzen]

Hello and thank you for the prompt response.

The current implementation uses --extern flags to tell rustc where the standard library dependencies are located. This runs into a few problems when a user attempts to use extern crate for a crate that was not included.

My understanding of this is that somewhere in my dependency tree there is an extern crate that is confusing cargo. My complete build command is cargo build -Z build-std --target wasm32-unknown-unknown which does not use the --extern flag, but there are a variety of uses of extern crate. If I try to isolate by subcrate, there does not seem to be a relevant pattern, for example this sub-crate compiles fine, but this one does not despite them having nearly identical commands:

#[cfg(not(feature = "std"))]
extern crate alloc;

and

#[cfg(not(feature = "std"))]
pub extern crate alloc;

respectively. So I assume the issue is with some upstream dependency, but I have not identified where it is yet.

[adamgemmell]

--extern is a rustc flag that cargo invokes, it's an internal detail of the build-std feature really.

The issue is that your target is panic_abort by default, but the current implementation of build-std doesn't build panic_abort by default. Thus rust fails to find the crate in the build-std sysroot and looks in the global sysroot, which I believe brings in another copy of core. Disabling this lookup in the global sysroot, as in the issue Eric mentioned, should give a better message in these situations (something like "uanble to find panic_abort").

In addition, #29 exists to try to handle panic strategies better to avoid users having to mess with building panic_abort or pass the panic_immediate_abort feature flag in the first place.

I need to it to build with just -Z build-std

That would be nice, but now the proper fix for you is to pass std,panic_abort to it as you've already found.

[ehuss]

Yea, I'm going to close as a duplicate of #29 and #31.