Closed tomaka closed 2 years ago
Same issue here. Here's what cargo nono
says:
libsecp256k1: FAILURE
- Did not find a #![no_std] attribute or a simple conditional attribute like #[cfg_attr(not(feature = "std"), no_std)] in the crate source. Crate most likely doesn't support no_std without changes.
log: FAILURE
bump
Doing some investigation because I would like to move this forward as well.
I believe the issue came from the changes in https://github.com/paritytech/libsecp256k1/pull/41/ which make use of allocation (Vec
and Box
)
Would like to know what everyone else thinks. At first glance, it does not seem possible to feature-gate behind feature = "std"
because the functions are used in the generators used in build.rs
Related: https://github.com/paritytech/libsecp256k1/issues/46
0.6.0
I am experiencing this issue in 0.6.0 with:
libsecp256k1 = { version="0.6.0", default-features=false, features=["static-context"] }
std duplicate method exceptions are thrown noting:
the lang item is first defined in crate `std` (which `libsecp256k1_core` depends on)
@samkirton that's strange...I just tried again with static-context
and could not reproduce this. Do you have another crate in your dependencies that is possibly enabling std
for libsecp256k1_core
?
The only other dependencies I have are:
rand = { version="0.7.3", optional = true }
sha2 = { version="0.9.5", default-features=false }
[features]
signing = ["rand", "libsecp256k1/hmac"]
where rand is turned on only for the signing feature
@samkirton I still can't reproduce your exact error message above, but I can reproduce a similar one when I use rand
as you have in your dependencies. You might need to turn off default-features for rand
if you're using no_std when the signing
feature is enabled.
Signing requires hmac, which requires std, so rand is only ever used for std builds. I will try and disable default features on rand though just incase optional = true
isn't working as I expected it to
Signing requires hmac, which requires std, so rand is only ever used for std builds.
Oh right, sorry.
@trevor-crypto I just tried to upgrade to 0.6.0 from 0.3.5 and getting std dependencies again. I guess it's expected based on your note above:
Signing requires hmac, which requires std, so rand is only ever used for std builds.
Does this mean that this crate no longer support signing with no_std? There must be a no_std version of hmac because 0.3.5 is depending on one.
I tried using the blank_with_context
variants thinking that the static-context
feature may have been the problem but it's not.
This dependency alone pulls in the std:
libsecp256k1 = { version = "0.6.0", default-features = false, features = [
"hmac"
] }
It would be great (or rather necessary) to have no_std signing feature like in earlier versions. My only known option is to downgrade to 0.3.5 which I'll have to patch because some of its dependencies are no longer on crates_io.
@fredfortier I submitted a PR. If you'd like you can test it out on my branch or wait for it to come into develop
I'm confused about this issue as well because cargo nono check
gives the dependency above (with only the hmac feature) a clear report, but the compiler gives an std error when I use it. I'll try your branch.
You did it @trevor-crypto . Your branch referenced above is now working for me when compiling to my no_std target.
This should be fixed now. Let me know if the error still exists.
This issue has the same title as https://github.com/paritytech/libsecp256k1/issues/68, but the problem isn't the same.
As of version 0.5.0/core-0.2.0, recently published on crates.io, compiling with
default-feature = false
leads to compilation errors in the core:To reproduce, just add
libsecp256k1 = { version = "0.5.0", default-features = false }
as a dependency to a project.