error[E0152]: duplicate lang item in crate `std` (which `indexmap` depends on): `panic_impl`.
Closed this issue · 4 comments
Hey,
I'm trying to use indexmap in a substrate pallet, which is a no_std
environment.
If I import: indexmap = { version = "1.9.2", default-features = false }
I get the following error:
error[E0152]: duplicate lang item in crate `std` (which `indexmap` depends on): `panic_impl`.
|
= note: the lang item is first defined in crate `sp_io` (which `frame_support` depends on)
= note: first definition in `sp_io` loaded from /Users/tdelabro/Documents/code/starkware/kaioshin/target/debug/wbuild/kaioshin-runtime/target/wasm32-unknown-unknown/release/deps/libsp_io-c4656f0a7cd2540b.rmeta
= note: second definition in `std` loaded from /Users/tdelabro/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libstd-d66a635e2d91bd07.rlib
For more information about this error, try `rustc --explain E0152`.
warning: `pallet-cairo-execution-engine` (lib) generated 1 warning
error: could not compile `pallet-cairo-execution-engine` (lib) due to previous error; 1 warning emitted
Which usually indicate that some crate uses an std
feature.
This import the following version:
[[package]]
name = "indexmap"
version = "1.9.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1885e79c1fc4b10f0e172c475f458b7f7b93061064d98c3293e98c5ba0c8b399"
dependencies = [
"autocfg",
"hashbrown 0.12.3",
"serde",
]
I can't find this commit on your repo so I have tried other versions of the crate: 4d410509d2e67c3d33e17c6d4cdbf622ea8458f8
and 4d52cf338c6ff9f742aac716f41b8a5497842f92
, which are the two last commits on your indexmap-1.x
release branch, both raise the same problem.
The strange thing is that any commit on the branch master
, including ca5f848e10c31e80aeaad0720d14aa2f6dd6cfb1
which is the commit of the release 1.9.2
are valid and does not raise any errors.
My conclusion is that there is something wicked with your indexmap-1.x
release branch.
A temporary fix is to use the master branch rather that the crate.io releases.
The "wicked" thing is that we added no_std
support after we had already released 1.0 as a std
-only crate, so the usual --no-default-features
method of avoiding std
was not possible. That is, someone could have already been running no-default and expecting std
-dependent methods to work. So instead, we added build-script detection for whether the target has a std
crate at all, and the manual "std"
feature only serves to skip that detection.
But this scheme doesn't work in your case, where you want to avoid std
lang items even when the target does support it. Version 2.0 will solve this by only using an explicit "std"
feature opt-in, not detection.
Okay, thank you for the explanations!
I will be using version 2.0-pre for now.
Best luck with your current work on this new version
Hello again @cuviper,
So I did what we said, using 2.0.0-pre
for now but it causes a problem mentioned here: starkware-libs/cairo#3297 (comment)
What do you think we can do?
Could you publish a 2.0.0-pre
to crates.io?
Could you just release 2.0.0
(or 1.10.0
if it's enough from a server point of view) where only the way no-std
is supported changes? And keep the other breaking changes for later?
Are there other options to explore?
Btw, if the problem is the amount of work it requires, I would happily prepare a PR myself for you to review and publish