Skip to content

🐛 "generate_keypair is not found" in version 0.15.4 #157

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.

Sign up for GitHub

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

Jump to bottom
Closed
qiangshou007 opened this issue Sep 9, 2019 · 2 comments · Fixed by #158
Closed

🐛 "generate_keypair is not found" in version 0.15.4 #157

qiangshou007 opened this issue Sep 9, 2019 · 2 comments · Fixed by #158

Comments

@qiangshou007
Copy link

qiangshou007 commented Sep 9, 2019 •
edited
Loading

mac
rustc 1.39.0-nightly (2b8116dce 2019-09-08)

change dependencies sepc256k1 version to 0.15.3, build Ok
secp256k1 = "=0.15.3"
@apoelstra
Copy link
Member

Oops, #153 was part of 0.15.4 but it shouldn't have been included in a minor version release.

@apoelstra apoelstra mentioned this issue Sep 9, 2019
Merged
@apoelstra
Copy link
Member

FYI for now using the rand-std feature rather than rand will fix it.

@apoelstra apoelstra mentioned this issue Sep 9, 2019
Closed
RandyMcMillan pushed a commit to gnostr-org/secp256k1 that referenced this issue Jul 2, 2024
@real-or-random
Merge bitcoin-core/secp256k1#1546: cmake: Rename `SECP256K1_LATE_CFLA…
d403eea 
…GS` and switch to Bitcoin Core's approach

4706be2 cmake: Reimplement `SECP256K1_APPEND_CFLAGS` using Bitcoin Core approach (Hennadii Stepanov)
c2764db cmake: Rename `SECP256K1_LATE_CFLAGS` to `SECP256K1_APPEND_CFLAGS` (Hennadii Stepanov)

Pull request description:

  This PR address this hebasto/bitcoin#239 (comment):
  > For consistency with libsecp256k1:
  >
  > > > Is this code block supposed to achieve the same as our `SECP256K1_LATE_CFLAGS` (implemented by a user-defined function `all_targets_add_compile_options`) in libsecp256k1?
  > >
  > >
  > > It is. But this approach guaranties to override even options that are abstracted by CMake, for instance [rust-bitcoin#157 (comment)](hebasto/bitcoin#157 (comment)).
  >
  >    * If we agree that appending to rule variables is superior, should we also do this in libsecp256k1?
  >
  >    * And/or should we rename the `SECP256K1_LATE_CFLAGS` variable to `APPEND_CFLAGS`?

ACKs for top commit:
  real-or-random:
    utACK 4706be2

Tree-SHA512: 24603886c4d6ab4e31836a67d5759f9855a60c6c9d34cfc6fc4023bd309cd51c15d986ac0b77a434f9fdc6d5e97dcd3b8484d8f5ef5d8f840f47dc141de18084
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Revert "Add a rand-std feature" rust-bitcoin/rust-secp256k1
2 participants
@apoelstra @qiangshou007