Relax cc dependency requirements, bump secp256k1 to 0.15 and bump version to 0.17.0

[jonasnick]

The current latest version of rust-bitcoinconsensus (0.16.4) is not compatible with secp256k1 0.13 since the cc requirements were relaxed (rust-bitcoin/rust-secp256k1#103). The result is that when we update to secp256k1 in rust-bitcoin rust will pick bitcoinconsensus 0.16.3. The problem is that rust 1.22 has a bug where the attempt to resolve dependencies in such a way leads to an infinite loop. My hypothesis is that this PR will fix the problem and allow rust-bitcoin to update its secp256k1 version (see PR rust-bitcoin/rust-bitcoin#278).

[jonasnick]

Travis fails because it runs tests with rustc 1.14 which rust-secp256k1 0.13 doesn't support anymore. No idea why the appveyor/windows tests fail.

[jonasnick]

Added commit to update the tests in travis and appveyor.

[apoelstra]

We should go straight to 0.14 - rust-bitcoin/rust-secp256k1#127

[jonasnick]

We can't simply update to secp256k1 0.14 because secp256k1_context_create were removed:

rust-bitcoinconsensus/bitcoin/src/pubkey.cpp:288: undefined reference to `secp256k1_context_create'

Looks like rust-bitcoinconsensus only imports rust-secp to link the C++ code against it. It would make sense to make this crate compile let its own libsecp now.
But afaik there's no namespacing and we could run into the same problems that we had in rust-secp256k1-zkp where you don't know against which secp you're linking (which is why we have this script in rust-secp-zkp to rename secp256k1_ to secp256k1_zkp_).

[apoelstra]

What a mess :(

[elichai]

Maybe a solution could be to make the compiling of libsecp in rust-secp256k1 optional and then you could link a different version? :/

[apoelstra]

@elichai letting rust-secp users replace the C bindings without replacing the ffi module is a recipe for horrifying UB

[elichai]

I hate linking problems.
Had similar problems in rust only too (rust-rocksdb/rust-rocksdb#308)

I don't see an easy solution to it without either side doing something weird. (adding some compilation condition to add/remove functions/libraries)

[elichai]

I have an idea on how to solve this.
We can write a simple rust shim that provides secp256k1_context_create and secp256k1_context_destroy functions. that way it could link against them.

If you think it's a good idea I can write that and open a PR here

[jonasnick]

@elichai Good idea imo!

[jonasnick]

Perhaps longer term it should be possible to add prefixes to libsecp symbols, similar to what boringssl does (briansmith/ring#849).

[apoelstra]

Longer term :) Hopefully we can find a solution that does not require go to build things.

[jonasnick]

Added commit to bump secp256k1 to 0.14(.1)

[elichai]

Shouldn't this be a major bump assuming these changes can break stuff if someone has an older rust-secp256k1?

[jonasnick]

Good point @elichai. Bumped to 0.17.0

[elichai]

Looks good! any ideas why it doesn't compile on Windows?(appveyor not passing)

Edit: I see now that it's broken since #7, so nvm.

[jonasnick]

I see now that it's broken since #7, so nvm.

There was an attempt to fix this in #8. I cherry picked the relevant commit. Let's see...

[jonasnick]

Pssh, new errors... I have no idea.

[elichai]

arghh.
It seems that this commits fix the current errors: rust-lang/cc-rs@9dcf641#diff-1636770f970629d064824915e71ea2cd

Could we relax cc more now that upstream has CI for both MSVC and Linux for 1.16.0?
https://github.com/alexcrichton/cc-rs/blob/master/azure-pipelines.yml
CC @TheBlueMatt

(If anyone knows of a way to test the windows builds on linux I can test different versions of cc before we relax anything)

[jonasnick]

As far as I can tell we'd have to

1. require at least cc 1.0.36 in rust-bitcoinconsensus
2. relax cc requirement in rust-secp256k1 to include 1.0.36

[apoelstra]

I think it's fine to support any cc as long as the minimum compiler version there is still 1.16.0

[elichai]

This seem to fix it: rust-bitcoin/rust-secp256k1#131

Tests: https://ci.appveyor.com/project/elichai/rust-bitcoinconsensus/builds/26027109
code: https://github.com/elichai/rust-bitcoinconsensus/tree/cc

It did also require enabling the recovery module because of missing secp256k1_ecdsa_recoverable_signature_parse_compact symbol (elichai@b15dae9)

[jonasnick]

@elichai great, thanks!

[tamasblummer]

checked OSX build and link with current rust-bitcoin master and secp256k1 v0.15.0

[tamasblummer]

checked Linux build and link with current rust-bitcoin master and secp256k1 v0.15.0