Ring: Recent update of cc dependency breaks compatibility with usage of other crates that restrict the version of cc

[reuvenpo]

This issue is identical to https://github.com/BLAKE3-team/BLAKE3/issues/83, and unfortunately isn't because you did anything wrong.
Some other crates, such as secp256k1-sys (which is a dependency of secp256k1) choose to restrict the versions of cc that they support as a dependency, because they set minimum supported compiler versions (1.22 in the case of secp). The cc crate has broken compatibility with the old compiler at some point, and so secp can not be used with the newer cc versions.
A recent commit in this repository, which was included in the 0.16.13 release of ring has changed the version of the cc dependency from 1.0.37 to 1.0.52. Since secp only supports cc versions between 1.0.28 and 1.0.41, that release broke builds of crates that want to use both ring and secp256k1.

If this update of the minimum supported cc version was not necessary, we would like to ask that you revert that change and make a new release, since it represents a regression for us.

Thank you for understanding! As stated at the beginning, this is not your fault, but a hassle caused by other crate's policies.

(By the way, the comment in your Cargo.toml file mentions that the version of cc should be the same as specified in pregenerate_asm/Cargo.toml, but that doesn't seem to be the case. I don't know what that means for this crate, but it might be it's own bug)

[Darkspirit]

secp256k1 broke other crates - like zstd-sys (cc ^1.0.45) - as well by putting a handbrake (cc <= 1.0.41) on the ecosystem.
They limit cc versions to keep an old MSRV. Forking and removing the restriction could be another solution.
https://github.com/rust-bitcoin/rust-secp256k1/issues/202
https://github.com/rust-bitcoin/rust-bitcoin/issues/338

[briansmith]

I will accept a PR that resets the cc-rs version to 1.0.41.

[reuvenpo]

We ended up taking your advice and forking the secp256k1 repository for our company's uses. We agree with the opinion that the rest of the ecosystem shouldn't have to bend to one crate that has very strict compatibility guarantees, if those guarantees are not relevant to other users.

And personally, this is much more reasonable than pinging random projects because a third party is causing issues.

I'm almost tempted to publish the fork to crates.io so people don't have to deal with this issue.

See https://github.com/enigmampc/rust-secp256k1/tree/remove-cc-version-limit

[briansmith]

OK. If somebody wants this done for 0.16.x, I would recommend they do it soon, as I'm hoping the last 0.16.x release will be very soon. Then I'll be working on 0.17.x and it would be unlikely that I'd release another 0.16.x version.

[reuvenpo]

On my team's end, this issue can be closed. You can keep it open if you find that someone cares about this.

To anyone else seeing this issue, feel free to use the fork i linked above.

[elichai]

I'm almost tempted to publish the fork to crates.io so people don't have to deal with this issue.

See https://github.com/enigmampc/rust-secp256k1/tree/remove-cc-version-limit

@reuvenpo
We fixed this in https://github.com/rust-bitcoin/rust-secp256k1/pull/204, as time went this became a real problem for users and we decided that whoever needs a bootstrapable compiler can pin their cc to 1.22, but other users shouldn't be penalized for that.

I hope we'll get a release out this week(depends on other PRs we might want to finish first)