-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
confusion about dependency versions #1418
Comments
After poking around some more, I found http://doc.crates.io/crates-io.html which I think answers all my questions (I should use |
Re-opening this because the documentation isn't clear. What I think it should say:
|
…15245) ### What does this PR try to resolve? GitHub Runner Images 20250224.5.0+ ship Windows 11 SDK 10.0.26100+ compared to the previous Windows 11 SDK 10.0.22621, which bumped the UCRT headers. The new UCRT headers use SSE2 types. However, `cc` versions <= 1.2.15 emit `/arch:IA32` for `x86` Windows targets for `clang-cl`, which causes compilation errors since `clang-cl` can't find SSE2 types without `/arch:SSE2` specified (or defaulted). (Note that MSVC at the time of writing silently accepts and emits instruments for code using SSE2 types, as opposed to `clang-cl` hard error-ing). `cc` 1.2.16 contains a fix for this problem, rust-lang/cc-rs#1425, to correctly emit `/arch:SSE2` instead of `/arch:IA32` to enable `clang-cl` to find the SSE2 types. However, cargo's `cc` currently is still on 1.2.13. To fix this for rust-lang/rust CI, we need to bump anything that transitively relies on `cc` and tries to use `clang-cl` on `x86` Windows targets to compile any C/C++ code that transitively use functions or types that require SSE2 types, such as `<wchar.h>`. ### How should we test and review this PR? The fix was initially intended for `rustc_{codegen_ssa,llvm}` `cc`, and based on testing in rust-lang/rust#137724, I was able to successfully build `rustc_{codegen_ssa,llvm}` with a forked `cc` based on 1.2.15 which contains the fix from rust-lang/cc-rs#1425. Note that in the same PR, while the compiler build succeeded, the build of cargo itself failed since it transitively used a `cc` *without* the fix to build `curl-sys`[^dep-chain], which failed as one might expect (`curl-sys` tries to build C code that uses `<wchar.h>` which runs into the same problem). Hence, this PR is opened to bump cargo's `cc` to a `cc` version containing the fix. ### Additional information This `x86` Windows CI problem is: - Discussed in https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/spurious.20.28.3F.29.20i686.20msvc.20errors. - Tracked by rust-lang/rust#137733. #### `cc` changelog between 1.2.13 and 1.2.16 <details> <summary>`cc` changes since 1.2.13 up to and including 1.2.16</summary> ##### [1.2.16](rust-lang/cc-rs@cc-v1.2.15...cc-v1.2.16) - 2025-02-28 ###### Fixed - force windows compiler to run in `out_dir` to prevent artifacts in cwd (#1415) ###### Other - use `/arch:SSE2` for `x86` target arch (#1425) - Regenerate windows-sys binding ([#1422](rust-lang/cc-rs#1422)) - Regenerate target info ([#1418](rust-lang/cc-rs#1418)) - Add LIB var when compiling flag_check (#1417) - Change flag ordering ([#1403](rust-lang/cc-rs#1403)) - Fix archiver detection for musl cross compilation ([#1404](rust-lang/cc-rs#1404)) ##### [1.2.15](rust-lang/cc-rs@cc-v1.2.14...cc-v1.2.15) - 2025-02-21 ###### Other - Regenerate target info ([#1406](rust-lang/cc-rs#1406)) - Always read from all `CFLAGS`-style flags ([#1401](rust-lang/cc-rs#1401)) - Simplify the error output on failed `Command` invocation ([#1397](rust-lang/cc-rs#1397)) ##### [1.2.14](rust-lang/cc-rs@cc-v1.2.13...cc-v1.2.14) - 2025-02-14 ###### Other - Regenerate target info ([#1398](rust-lang/cc-rs#1398)) - Add support for setting `-gdwarf-{version}` based on RUSTFLAGS ([#1395](rust-lang/cc-rs#1395)) - Add support for alternative network stack io-sock on QNX 7.1 aarch64 and x86_64 ([#1312](rust-lang/cc-rs#1312)) </details> [^dep-chain]: I think the dep chain is something like git2 -> libgit2-sys -> curl -> curl-sys?
I am pretty sure cargo is working as intended, but I'm a bit confused by how Cargo handles dependency versions.
I started a new cargo project, and added regex as a dependency:
I picked version 0.1.19 since at the time of this writing, that is the latest version on http://crates.io/
Trying to build (full errors omited for brevity)
I now think "Hm, I wonder if a different version of regex might work", so I make a change to Cargo.toml and try again:
I wrote my dependency as 0.1.18, yet Cargo is still trying to build 0.1.19. Since 0.1.19 must be backwards compatible with 0.1.18, I'm guessing that Cargo is assuming that 0.1.19 will work, it automatically gets the latest version.
I discovered I can force a specific version with
cargo update -p regex --precise 0.1.18
:My first question is: is Cargo doing the expected thing?
My second question is: if Cargo is going to automatically upgrade dependencies to the latest compatible patch release, what would be the point in specifying a version like
0.1.19
instead of0.1
?My third question is: If I'm writing a library with a dependency on a specific patch level, what do I put in my Cargo.toml file to get Cargo to use the specific version that I specified?
(Edit) Forth question: I couldn't find any of these details in any documentation. If I missed it, where should I look?
The text was updated successfully, but these errors were encountered: