Cargo fails to select version; misinterprets semver as =version

I have several C dependencies which all use semver (caret) references to the cc crate as a build dependency.
Despite this, and despite the versions only differing by patch level, cargo fails to select a version.

What's interesting is that cargo interprets a semver as an =version spec instead of a ^version spec.

crates.io does not: https://crates.io/crates/libwebp-sys

The source Cargo.toml in both libwebp-sys and c_components is clearly a semver:

The error message

error: failed to select a version for `cc`.
    ... required by package `libwebp-sys v0.3.0`
    ... which is depended on by `imageflow_core v0.1.0 (https://github.com/imazen/imageflow?tag=v1.3.6-rc36#04bb1412)`
    ... which is depended on by `imageflow_node v0.1.1 (/home/lilith/imazen/imageflow-node/native)`
versions that meet the requirements `= 1.0.45` are: 1.0.45

all possible versions conflict with previously selected packages.

  previously selected package `cc v1.0.52`
    ... which is depended on by `imageflow_c_components v0.1.0 (https://github.com/imazen/imageflow?tag=v1.3.6-rc36#04bb1412)`
    ... which is depended on by `imageflow_core v0.1.0 (https://github.com/imazen/imageflow?tag=v1.3.6-rc36#04bb1412)`
    ... which is depended on by `imageflow_node v0.1.1 (/home/lilith/imazen/imageflow-node/native)`

failed to select a version for `cc` which could resolve this conflict

cargo -V
cargo 1.43.0 (3532cf738 2020-03-17)

To reproduce

Add imageflow_abi = { git = "https://github.com/imazen/imageflow", tag="v1.3.6-rc36" } to any Cargo.toml and run cargo build

It's also worth noting this only happens as a deeper transitive dependency; the imageflow_abi crate compiles fine, but fails to compile when used as a dependency.

This did not reproduce the problem for me. I created a new Cargo project, added this line to the dependencies section, and it built successfully using cc 1.0.52.

Do you have any dependency overrides in your Cargo.toml or .cargo/config?

None, but I tried deleting Cargo.lock and it worked! Apparently something from a previous build was causing it.

The purpose of Cargo.lock is to lock specific versions in place.

Thank you. I don't think I'll repeat this particular mistake. For some reason I thought I'd already deleted it.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.