Skip to content
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.

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

Disable bindgen and upgrade libsecp256k1 #83

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

xoloki
Copy link
Contributor

@xoloki xoloki commented Oct 10, 2024

Fixes #82

@xoloki xoloki requested a review from djordon October 10, 2024 04:19
Copy link

cloudflare-workers-and-pages bot commented Oct 10, 2024

Deploying p256k1 with  Cloudflare Pages  Cloudflare Pages

Latest commit: 83fa426
Status: ✅  Deploy successful!
Preview URL: https://ea1450f6.p256k1.pages.dev
Branch Preview URL: https://disable-bindgen-and-upgrade.p256k1.pages.dev

View logs

@jcnelson
Copy link
Contributor

I can confirm that both cargo build and cargo test succeed on musl libc Linux without any special tweaking.

@djordon
Copy link

djordon commented Oct 10, 2024

I take it that this is basically just a git pull && git checkout TAG from the libsecp256k1 repo? Or is it more than just that?

Side note: I would consider using git submodules for the secp256k1 source. I assume everything in the p256k1/_secp256k1 folder is basically a specific commit of the secp256k1 repo, but it's quite hard to tell for sure. Using a submodule would make it clear what's going on and make it easy to point out any of the changes on top of the source from secp256k1. And if you want to ensure the source of the submodule is always under your control, I'd set up a mirror of the bitcoin-core/secp256k1 repo and point my submodule to that. The main benefit here is that the diffs are super clear and easy to reconcile. Any thoughts?

@xoloki
Copy link
Contributor Author

xoloki commented Oct 10, 2024

I take it that this is basically just a git pull && git checkout TAG from the libsecp256k1 repo? Or is it more than just that?

It's a download not a checkout:

https://github.com/Trust-Machines/p256k1/blob/master/update/src/main.rs#L11

Side note: I would consider using git submodules for the secp256k1 source. I assume everything in the p256k1/_secp256k1 folder is basically a specific commit of the secp256k1 repo, but it's quite hard to tell for sure. Using a submodule would make it clear what's going on and make it easy to point out any of the changes on top of the source from secp256k1. And if you want to ensure the source of the submodule is always under your control, I'd set up a mirror of the bitcoin-core/secp256k1 repo and point my submodule to that. The main benefit here is that the diffs are super clear and easy to reconcile. Any thoughts?

That's how I originally structured the repo. But in bf6d61b it was changed to do the current download/patch/vendor/define dance. Part of the reason was to get rid of conflicting symbols when stacks-core had multiple versions of different secp256k1 wrappers. But yeah definitely worth reconsidering now that bindgen is no longer working as it did originally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Upgrade libsecp256k1 dependency and disable bindgen in default-features
3 participants