no-std support broken in 0.5.0 about libsecp256k1

[trevor-crypto]

@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

[fredfortier]

You did it @trevor-crypto . Your branch referenced above is now working for me when compiling to my no_std target.

[fredfortier]

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

[tomusdrw]

bump

[trevor-crypto]

Doing some investigation because I would like to move this forward as well.

I believe the issue came from the changes in #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: #46

[trevor-crypto]

#75 should resolve this issue, which is in 0.6.0

[samkirton]

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)

[trevor-crypto]

@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?

[samkirton]

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

[trevor-crypto]

@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.

[samkirton]

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

[trevor-crypto]

Signing requires hmac, which requires std, so rand is only ever used for std builds.

Oh right, sorry.

[fredfortier]

@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.

[fredfortier]

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'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.

[sorpaas]

This should be fixed now. Let me know if the error still exists.