Unpin `cc` and upgrade to the latest version #131070

tgross35 · 2024-09-30T17:32:23Z

cc was previously pinned because 1.1.106 dropped support for Visual Studio 12 (2013), and we wanted to decouple that from the rest of the automated updates. As noted in 2, there is no longer anything indicating we support VS2013, so it should be okay to unpin it.

cc 1.1.22 contains a fix that may help improve the high MSVC CI failure rate 3, so we also have motivation to update to that point.

try-job: x86_64-msvc-ext

r? @ChrisDenton
cc @dpaoliello
cc @Mark-Simulacrum (from #128722 (comment))

`cc` was previously pinned because version 1.1.106 dropped support for Visual Studio 12 (2013), and we wanted to decouple that from the rest of the automated updates. As noted in [2], there is no longer anything indicating we support VS2013, so it should be okay to unpin it. `cc` 1.1.22 contains a fix that may help improve the high MSVC CI failure rate [3], so we also have motivation to update to that point. [1]: rust-lang#129307 [2]: rust-lang#129307 (comment) [3]: rust-lang#127883

rustbot · 2024-09-30T17:32:34Z

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

tgross35 · 2024-09-30T17:34:31Z

@bors try
@bors rollup=iffy

bors · 2024-09-30T17:35:41Z

⌛ Trying commit eaaa943 with merge 4fc810a...

Unpin `cc` and upgrade to the latest version `cc` was previously pinned because 1.1.106 dropped support for Visual Studio 12 (2013), and we wanted to decouple that from the rest of the automated updates. As noted in [2], there is no longer anything indicating we support VS2013, so it should be okay to unpin it. `cc` 1.1.22 contains a fix that may help improve the high MSVC CI failure rate [3], so we also have motivation to update to that point. [1]: rust-lang#129307 [2]: rust-lang#129307 (comment) [3]: rust-lang#127883 try-job: x86_64-msvc-ext

tgross35 · 2024-09-30T17:36:12Z

Probably @bors rollup=never actually...

ChrisDenton · 2024-09-30T17:49:39Z

👍 from me but this really should have a T-compiler reviewer

tgross35 · 2024-09-30T18:04:31Z

Yeah you're right, thanks for confirming

r? compiler

bors · 2024-09-30T19:17:06Z

☀️ Try build successful - checks-actions
Build commit: 4fc810a (4fc810ab099f1e4ec723e4cdd5f322502f8ba5e0)

wesleywiser

Tagging as relnote but as VS 2013 has been out of support for months-to-years (depending on whether you count extended support or not), I don't think this will be a big deal for users.

wesleywiser · 2024-10-01T16:19:40Z

@bors r+

bors · 2024-10-01T16:19:43Z

📌 Commit eaaa943 has been approved by wesleywiser

It is now in the queue for this repository.

bors · 2024-10-02T00:35:44Z

⌛ Testing commit eaaa943 with merge 1d71891...

bors · 2024-10-02T03:25:05Z

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing 1d71891 to master...

rust-timer · 2024-10-02T05:02:30Z

Finished benchmarking commit (1d71891): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 1.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.0%	[1.0%, 1.0%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.0%	[1.0%, 1.0%]	1

Cycles

Results (primary -2.6%, secondary -2.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.6%	[-2.6%, -2.6%]	1
Improvements ✅ (secondary)	-2.1%	[-2.5%, -1.8%]	5
All ❌✅ (primary)	-2.6%	[-2.6%, -2.6%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 770.288s -> 770.698s (0.05%)
Artifact size: 341.52 MiB -> 341.48 MiB (-0.01%)

alexcrichton · 2024-10-22T20:55:37Z

I've recently tried to update the nightly we use in Wasmtime's CI and it's failing. After that I minimized the CI failure and ran a "bisection on github" which yielded this regression range. Within that range is this PR updating the cc crate, and the specific error we're running into looks like:

CUSTOMBUILD : error : linking with `link.exe` failed: exit code: 1120 [D:\a\wasmtime\wasmtime\target\c-api-build\wasmtime-crate.vcxproj]
    |
    = note: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\VC\\Tools\\MSVC\\14.41.34120\\bin\\HostX64\\x64\\link.exe" "/DEF:C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\rustcQmo3vX\\lib.def" "/NOLOGO" "C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\rustcQmo3vX\\symbols.o" "D:\\a\\wasmtime\\wasmtime\\target\\aarch64-pc-windows-msvc\\release\\deps\\wasmtime.wasmtime.5d0bb5c93767783-cgu.0.rcgu.o" "C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\rustcQmo3vX\\libwasmtime-23b1ceb4a4c3125e.rlib" "C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\rustcQmo3vX\\libstd-cc044fac50b9bc2f.rlib" "D:\\a\\wasmtime\\wasmtime\\target\\aarch64-pc-windows-msvc\\release\\deps\\libcompiler_builtins-bac3a61622f83a04.rlib" "legacy_stdio_definitions.lib" "C:\\Users\\runneradmin\\.cargo\\registry\\src\\index.crates.io-6f17d22bba15001f\\windows_aarch64_msvc-0.52.6\\lib\\windows.0.52.0.lib" "kernel32.lib" "kernel32.lib" "advapi32.lib" "ntdll.lib" "userenv.lib" "ws2_32.lib" "dbghelp.lib" "/defaultlib:libcmt" "/NXCOMPAT" "/LIBPATH:C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\VC\\Tools\\MSVC\\14.41.34120\\atlmfc\\lib\\arm64" "/LIBPATH:D:\\a\\wasmtime\\wasmtime\\target\\aarch64-pc-windows-msvc\\release\\build\\wasmtime-e3ab72304732b115\\out" "/LIBPATH:C:\\Users\\runneradmin\\.cargo\\registry\\src\\index.crates.io-6f17d22bba15001f\\windows_aarch64_msvc-0.52.6\\lib" "/OUT:D:\\a\\wasmtime\\wasmtime\\target\\aarch64-pc-windows-msvc\\release\\deps\\wasmtime.dll" "/OPT:REF,ICF" "/DLL" "/IMPLIB:D:\\a\\wasmtime\\wasmtime\\target\\aarch64-pc-windows-msvc\\release\\deps\\wasmtime.dll.lib" "/DEBUG" "/PDBALTPATH:%_PDB%" "/NATVIS:C:\\Users\\runneradmin\\.rustup\\toolchains\\nightly-2024-10-03-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\intrinsic.natvis" "/NATVIS:C:\\Users\\runneradmin\\.rustup\\toolchains\\nightly-2024-10-03-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\liballoc.natvis" "/NATVIS:C:\\Users\\runneradmin\\.rustup\\toolchains\\nightly-2024-10-03-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\libcore.natvis" "/NATVIS:C:\\Users\\runneradmin\\.rustup\\toolchains\\nightly-2024-10-03-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\libstd.natvis"
    = note:    Creating library D:\a\wasmtime\wasmtime\target\aarch64-pc-windows-msvc\release\deps\wasmtime.dll.lib and object D:\a\wasmtime\wasmtime\target\aarch64-pc-windows-msvc\release\deps\wasmtime.dll.expΓÉì
wasmtime.wasmtime.5d0bb5c93767783-cgu.0.rcgu.o : error LNK2019: unresolved external symbol memcpy referenced in function _ZN132_$LT$alloc..vec..Vec$LT$T$C$A$GT$$u20$as$u20$alloc..vec..spec_extend..SpecExtend$LT$$RF$T$C$core..slice..iter..Iter$LT$T$GT$$GT$$GT$11spec_extend17hd634bb8c4092ac00EΓÉì [D:\a\wasmtime\wasmtime\target\c-api-build\wasmtime-crate.vcxproj]
...
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.41.34120\lib\x64\legacy_stdio_definitions.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'ARM64'ΓÉì [D:\a\wasmtime\wasmtime\target\c-api-build\wasmtime-crate.vcxproj]
C:\Program Files (x86)\Windows Kits\10\lib\10.0.20348.0\um\x64\kernel32.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'ARM64'ΓÉì [D:\a\wasmtime\wasmtime\target\c-api-build\wasmtime-crate.vcxproj]
C:\Program Files (x86)\Windows Kits\10\lib\10.0.20348.0\um\x64\advapi32.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'ARM64'ΓÉì [D:\a\wasmtime\wasmtime\target\c-api-build\wasmtime-crate.vcxproj]
C:\Program Files (x86)\Windows Kits\10\lib\10.0.20348.0\um\x64\ntdll.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'ARM64'ΓÉì [D:\a\wasmtime\wasmtime\target\c-api-build\wasmtime-crate.vcxproj]
C:\Program Files (x86)\Windows Kits\10\lib\10.0.20348.0\um\x64\userenv.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'ARM64'ΓÉì [D:\a\wasmtime\wasmtime\target\c-api-build\wasmtime-crate.vcxproj]
C:\Program Files (x86)\Windows Kits\10\lib\10.0.20348.0\um\x64\ws2_32.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'ARM64'ΓÉì [D:\a\wasmtime\wasmtime\target\c-api-build\wasmtime-crate.vcxproj]
C:\Program Files (x86)\Windows Kits\10\lib\10.0.20348.0\um\x64\dbghelp.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'ARM64'ΓÉì [D:\a\wasmtime\wasmtime\target\c-api-build\wasmtime-crate.vcxproj]
D:\a\wasmtime\wasmtime\target\aarch64-pc-windows-msvc\release\deps\wasmtime.dll : fatal error LNK1120: 15 unresolved externalsΓÉì [D:\a\wasmtime\wasmtime\target\c-api-build\wasmtime-crate.vcxproj]
            
  
CUSTOMBUILD : error : could not compile `wasmtime-c-api` (lib) due to 1 previous error [D:\a\wasmtime\wasmtime\target\c-api-build\wasmtime-crate.vcxproj]

I unfortunately can't reproduce this locally and I think it's likely relatively specific to the setup of CI. I for example don't know what toolchain components are installed on github actions on Windows for the various bits and pieces here.

All that's to say that I think this PR's update is the likely cause of the build issue we're running into. I certainly won't go so far as to say that this is the component at fault, it's probably just uncovering something about how we're configuring CI wrong or something like that.

Specifically the shape of the issue is:

We're building a release binary for aarch64-pc-windows-msvc on CI
This is running on today's windows-latest which is x64 which means this is a cross-compile
We're using CMake to run the build, so it's github actions calls bash (a script) calls cmake calls rustc.
CMake is using what I believe is MSBuild as the build system

If I had to hazard a guess what I would suspect is happening is that MSBuild doesn't know it's doing a cross compile (I have no idea how one would configure it to do so if this is the case) and so it's setting some env vars which this cc crate update is then picking up and forwarding to rustc and somehow causing x64 libs to be used instead of arm64 libs.

Apologies for the long explanation here, but what I wanted to ask here is (a) if this is a known "change" that might happen with updating cc and (b) is there someone who might be best to ping about this and help figure out a good solution here? (e.g. an issue here, an issue on cc, just go fix this in Wasmtime, etc)

tgross35 · 2024-10-22T21:20:29Z

@alexcrichton are you familiar with the issue at #127883? We have been seeing issues with link.exe and others that only happen in CI (no local reproduction) for a few months now. There was a problem in a specific version of cc that made things worse (100% failure rate so we could never bump there), the version here includes a fix for that. But maybe there is something else going on with cc?

Probably worth bringing up in the Zulip thread, https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Spurious.20CI.20errors.20on.20x86_64-msvc-ext

alexcrichton · 2024-10-22T21:23:06Z

Oh I don't think this is related to that in that this isn't a spurious error it's a deterministic error from what I've seen so far. This PR being the "cause" is I presume due to some change between 1.0.105 and 1.1.23 for cc and how it interacts with msvc compiles and such

tgross35 · 2024-10-22T22:20:36Z

We actually did have something similar where it was failing 100% of the time bumping 1.0.99 to 1.1.22, in #130720, which was bisected to a caching change in 1.0.101. This PR just includes a fix for that. But there were a lot of other things updated for MSVC within bumped versions rust-lang/cc-rs@cc-v1.0.105...cc-v1.1.23.

Any chance you are able to adjust cc's version and see how that changes things? That is more or less what I did to narrow down this bad cc version in #130908.

@ChrisDenton might have other ideas. There is definitely something weird going on with cc+GHA+MSVC...

ChrisDenton · 2024-10-22T22:52:06Z

@alexcrichton This looks like a real error to me and I suspect this is a case where we have to make someone unhappy. cc-rs tries to respect external build systems (such as cmake and msbuild) because people often don't like us clobbering them. This complicates things and is made harder when build scripts are involved, as obviously they are compiled for the host rather than the target.

From what I can tell, it looks like the environment is set up to target x64 but is compiling for aarch64. You could maybe try setting VSCMD_ARG_TGT_ARCH environment variable to "x64", This should (hopefully!) trigger the cc-rs logic that attempts to fix up a wrong target.

Otherwise you may want to open an issue on the cc-rs repo to figure out what's going on in your build and if we can make things work again without breaking other people or if we need to reevaluate some trade-offs that have been made.

alexcrichton · 2024-10-22T22:59:20Z

Ah ok that makes sense, thanks for explaining! I think bisection of cc is difficult here since it's not a build script causing the issue but it's actually rustc itself so I'd have to create a number of custom compilers each with a different version of cc which is a bit of an investment to do.

I'll try to poke around and see if there's an "official" way to tell CMake that we're cross-compiling so it would hopefully forward different flags to the MSBuild generator. Either that or I'll probably just switch to Ninja which I predict won't have this issue. Failing all that I'll test out VSCMD_ARG_TGT_ARCH and see how it goes.

Thanks again for the info!

alexcrichton · 2024-10-23T15:02:05Z

Updating CMake to use Ninja did the trick so it looks like it was indeed MSBuild setting variables since MSBuild didn't think it was cross-compiling.

rustbot assigned ChrisDenton Sep 30, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 30, 2024

tgross35 mentioned this pull request Sep 30, 2024

We should document the exact minimum versions of build tools required to build a given Rust toolchain #129307

Open

rustbot assigned wesleywiser and unassigned ChrisDenton Sep 30, 2024

wesleywiser approved these changes Oct 1, 2024

View reviewed changes

wesleywiser added the relnotes Marks issues that should be documented in the release notes of the next release. label Oct 1, 2024

rustbot mentioned this pull request Oct 1, 2024

Tracking issue for release notes of #131070: Unpin cc and upgrade to the latest version #131100

Open

3 tasks

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 1, 2024

bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 2, 2024

bors merged commit 1d71891 into rust-lang:master Oct 2, 2024
7 checks passed

rustbot added this to the 1.83.0 milestone Oct 2, 2024

tgross35 deleted the update-root-cc branch October 2, 2024 03:29

arttet mentioned this pull request Oct 10, 2024

Unknown architecture for macOS target when we build psm #130844

Closed

arttet mentioned this pull request Oct 10, 2024

Bump cc dependency rust-lang/stacker#101

Merged

jieyouxu added the CI-spurious-fail-msvc CI spurious failure: target env msvc label Oct 15, 2024

alexcrichton mentioned this pull request Oct 22, 2024

Bump MSRV to 1.80 bytecodealliance/wasmtime#9496

Merged

alexcrichton mentioned this pull request Oct 23, 2024

Update nightly in CI bytecodealliance/wasmtime#9501

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unpin `cc` and upgrade to the latest version #131070

Unpin `cc` and upgrade to the latest version #131070

tgross35 commented Sep 30, 2024 •

edited

Loading

rustbot commented Sep 30, 2024

tgross35 commented Sep 30, 2024 •

edited

Loading

bors commented Sep 30, 2024

tgross35 commented Sep 30, 2024

ChrisDenton commented Sep 30, 2024

tgross35 commented Sep 30, 2024

bors commented Sep 30, 2024

wesleywiser left a comment

wesleywiser commented Oct 1, 2024

bors commented Oct 1, 2024

bors commented Oct 2, 2024

bors commented Oct 2, 2024

rust-timer commented Oct 2, 2024

alexcrichton commented Oct 22, 2024

tgross35 commented Oct 22, 2024

alexcrichton commented Oct 22, 2024

tgross35 commented Oct 22, 2024

ChrisDenton commented Oct 22, 2024

alexcrichton commented Oct 22, 2024

alexcrichton commented Oct 23, 2024

Unpin cc and upgrade to the latest version #131070

Unpin cc and upgrade to the latest version #131070

Conversation

tgross35 commented Sep 30, 2024 • edited Loading

rustbot commented Sep 30, 2024

tgross35 commented Sep 30, 2024 • edited Loading

bors commented Sep 30, 2024

tgross35 commented Sep 30, 2024

ChrisDenton commented Sep 30, 2024

tgross35 commented Sep 30, 2024

bors commented Sep 30, 2024

wesleywiser left a comment

Choose a reason for hiding this comment

wesleywiser commented Oct 1, 2024

bors commented Oct 1, 2024

bors commented Oct 2, 2024

bors commented Oct 2, 2024

rust-timer commented Oct 2, 2024

Overall result: ✅ improvements - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

alexcrichton commented Oct 22, 2024

tgross35 commented Oct 22, 2024

alexcrichton commented Oct 22, 2024

tgross35 commented Oct 22, 2024

ChrisDenton commented Oct 22, 2024

alexcrichton commented Oct 22, 2024

alexcrichton commented Oct 23, 2024

Unpin `cc` and upgrade to the latest version #131070

Unpin `cc` and upgrade to the latest version #131070

tgross35 commented Sep 30, 2024 •

edited

Loading

tgross35 commented Sep 30, 2024 •

edited

Loading