-
Notifications
You must be signed in to change notification settings - Fork 281
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
Add secp256k1-sys with prefixed sources #169
Conversation
f5b52d1
to
6aac0f4
Compare
idk about this. Even if other people do want this i'll split it to ~3 PRs. because right now it's not auditable. |
cc5b3e9
to
267ba31
Compare
That was an accident. Fixed that with patch files.
What's wrong with one PR with 3 commits? The creating the -sys crate and moving the dep is not possible to do in 2 commits without having a giant diff of first adding the entire depend folder a second time in another place and then removing the original in a second commit instead of having git treat them as a move. I can do that if that is favorable, but that was the reason I did the -sys crate together with migrating secp to -sys in the same commit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch @elichai, bitcoin-consensus relies on the secp symbol names (because it links libbitcoinsensus with libsecp which has been provided with rust-secp). Not sure what's the best way to solve this.
Fwiw I don't find this PR impossible to review and not sure how 3 PRs would help.
How would LTO take care of this? It doesn't, by default. Also there could be multiple versions of the library in play which can't be solved automatically.
@stevenroose travis doesn't run the -sys tests. It's just a meaningless single test, but would be better to add to travis, so we don't forget it in the future.
@@ -764,3 +785,4 @@ mod tests { | |||
assert_eq!(orig.len(), unsafe {strlen(test.as_ptr())}); | |||
} | |||
} | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is that intentional? you've done that a couple of times.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the ending newline? no idea, I think my vim might not like files without them perhaps? can I consider this a nit? :)
@jonasnick I forgot about reviewing commit by commit, I'll try that. Sorry. Isn't the whole point of LTO is to remove code duplication? So if you link against two versions of libsecp but with different symbols then most of the duplication should disappear it you use LTO. |
@@ -2,13 +2,13 @@ ACLOCAL_AMFLAGS = -I build-aux/m4 | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, we don't use the makefile/autotools. so there's no actual reason to change anything there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is just the auto replace at work.
@@ -5,8 +5,8 @@ import sys | |||
load("group_prover.sage") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sage too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This basically checks out libsecp in the depends/secp256k1 folder and then changes the variables and removes the allocation code. Nothing more. So yeah some unused artifacts are there.
@elichai just to clarify, are you aware that this PR contains a script |
@jonasnick well we still need to review that the script did it's job currently and then the person who ran it didn't change anything. Is it possible in C to have private functions? or all functions are "public" so we need to mangle all their names? even inner functions |
You can verify the script then run it yourself. But okay. Just renaming may introduce bugs that are not caught by the compiler. But that seems highly unlikely and will also be difficult to notice in manual review.
Are you suggesting to have a more complicated script that only looks at the exported symbols? Why? |
@elichai so you can run the following command to verify the depends folder:
The commit has is committed in the |
151acda
to
f1bbc2e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approach ACK
My feeling is that the entire approach needs some README file or similar. What is done here, and the reason why it's done is really not trivial. People not familiar which the project will think we're crazy.
If we anyway clone secp256k1, could we remove it entirely? Probably not because then you need to be online for building and we trust Github more? It's just a wild thought, please ignore me if this is stupid. |
@stevenroose I tried to link this against upstream and @TheBlueMatt How are you fixing this here? (I tried turning LTO on but I still get link errors) |
|
||
# Use this feature to not compile the bundled libsecp256k1 C symbols, | ||
# but use external ones. | ||
external-symbols = ["secp256k1-sys/external-symbols"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you just not depend on secp256k1-sys at all if you build with external-symbols? pulling in a dummy crate as a dependency sucks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The crate is still defining the C interface and the FFI objects used in it. In fact it's not doing less than when built without external-symbols
, it's just the build.rs construction is no longer utilized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least we should add a scarier warning.
Also, as you noted in another channel, this has the potential to cause UB a user is using an old version of rust-secp, as well as this one with external-symbols
enabled...so we can't depend on cargo failing if this is enabled on a cargo build.
We're only cloning it when we revendor. That only needs to happen when updated to a new version. The sources are still required for being able to build. |
d2cd901
to
0093a5d
Compare
When we merge this let's be sure to get #162 in as well. |
Any updates on this? |
@@ -365,7 +386,7 @@ unsafe fn strlen(mut str_ptr: *const c_char) -> usize { | |||
/// Rust doesn't promise what pointers does it give to ZST (https://doc.rust-lang.org/nomicon/exotic-sizes.html#zero-sized-types-zsts) | |||
/// In case the type is empty this trait will give a NULL pointer, which should be handled in C. | |||
/// | |||
pub(crate) trait CPtr { | |||
pub trait CPtr { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a late PR I'll try move this to secp256k1
and not -sys
and make it pub(crate)
again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this not used in -sys? In that case I can move it.. The idea is to try and reduce the times we need to bump a -sys version. So I think better make breaking changes now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, seems to be used in macros as well. Yeah I think I'd prefer to merge this as is :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merge != release.
let's not change this PR any more so it can get merged at some point :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK code review.
ACK reproduced the same changes by the script.
0093a5d
I'm still not so sure about this script but I guess that's the best we can do right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK on the diff
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK on latest diff
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK. I was suspicious about this script but it's actually pretty great.
needs rebase :/ |
This feature disables using the bundles sources and will link into existing libsecp256k1 symbols.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK
Reviewed the diff from my last ACK
I'm adding a secp256k1-sys crate with just the FFI wrapper of the C libsecp.
And then I added a script (thanks @jonasnick) to prefix the secp sources with a rust-secp specific tag and a version tag, so that we don't suffer from naming conflicts anymore.