Starting with nightly-2021-01-13 (1.51) rustc fails to build archives on Windows 7

[MSxDOS]

E.g. cargo check --verbose on https://github.com/japaric/ufmt

F:\ufmt-master>cargo check --verbose
   Compiling unicode-xid v0.2.1
       Fresh ufmt-write v0.1.0 (F:\ufmt-master\write)
     Running `rustc --crate-name unicode_xid F:\.cargo\registry\src\github.com-1ecc6299db9
ec823\unicode-xid-0.2.1\src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,art
ifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -
-cfg "feature=\"default\"" -C metadata=df09097284490053 -C extra-filename=-df0909728449005
3 --out-dir F:\ufmt-master\target\debug\deps -L dependency=F:\ufmt-master\target\debug\dep
s --cap-lints allow`
       Fresh proc-macro-hack v0.5.19
   Compiling proc-macro2 v1.0.24
     Running `rustc --crate-name proc_macro2 --edition=2018 F:\.cargo\registry\src\github.
com-1ecc6299db9ec823\proc-macro2-1.0.24\src\lib.rs --error-format=json --json=diagnostic-r
endered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no
-C debuginfo=2 --cfg "feature=\"default\"" --cfg "feature=\"proc-macro\"" -C metadata=b463
43984a7d2c00 -C extra-filename=-b46343984a7d2c00 --out-dir F:\ufmt-master\target\debug\dep
s -L dependency=F:\ufmt-master\target\debug\deps --extern unicode_xid=F:\ufmt-master\targe
t\debug\deps\libunicode_xid-df09097284490053.rmeta --cap-lints allow --cfg lexerror_displa
y --cfg hygiene --cfg use_proc_macro --cfg wrap_proc_macro --cfg proc_macro_span`
error: failed to build archive: permission denied

error: aborting due to previous error

error: could not compile `unicode-xid`

Caused by:
  process didn't exit successfully: `rustc --crate-name unicode_xid F:\.cargo\registry\src
\github.com-1ecc6299db9ec823\unicode-xid-0.2.1\src\lib.rs --error-format=json --json=diagn
ostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitc
ode=no -C debuginfo=2 --cfg "feature=\"default\"" -C metadata=df09097284490053 -C extra-fi
lename=-df09097284490053 --out-dir F:\ufmt-master\target\debug\deps -L dependency=F:\ufmt-
master\target\debug\deps --cap-lints allow` (exit code: 1)
warning: build failed, waiting for other jobs to finish...
error: failed to build archive: permission denied

error: aborting due to previous error

error: build failed

rustc 1.51.0-nightly (e38fb306b 2021-01-14)
binary: rustc
commit-hash: e38fb306b7f5e65cca34df2dab1f0db15e1defb4
commit-date: 2021-01-14
host: x86_64-pc-windows-msvc
release: 1.51.0-nightly
LLVM version: 11.0

[tesuji]

Cannot reproduce on Windows target on CI.
Maybe check you systems again.

[MSxDOS]

The failure happens on a Windows 7 x64 machine. I reproduced this on another machine running Windows 7 x86, this time with i686-pc-windows-gnu toolchain.

[tesuji]

I don't have any Windows machine to test (left alone Windows 7 which not available on CI).
All builds on Windows 10 with msvc and gnu toolchain succeeded: https://github.com/lzutao/ufmt/runs/1717188912?check_suite_focus=true

Let's ping Windows group to see if any folks can verify the issue:
@rustbot ping windows

[rustbot]

Error: Only Rust team members can ping teams.

Please let @rust-lang/release know if you're having trouble with this bot.

[LeSeulArtichaut]

@rustbot ping windows

[rustbot]

Hey Windows Group! This bug has been identified as a good "Windows candidate".
In case it's useful, here are some instructions for tackling these sorts of
bugs. Maybe take a look?
Thanks! <3

cc @arlosi @danielframpton @gdr-at-ms @kennykerr @luqmana @lzybkr @nico-abram @retep998 @rylev @sivadeilra

[sivadeilra]

Speaking for the Windows team at Microsoft, Windows 7 has reached End of Life. We're not interested in providing any further support for Win 7 development.

We (and members of the Rust community) are also actively working on min_api_target_version RFC, which would officially deprecate some older Windows platforms (those that are EOL) for Rust.

I realize that this position may not be satisfying. However, we have to draw the line somewhere on supporting old versions of OSes, and Windows 7 has reached its official EOL. You may still be able to target Windows 7, by cross-compiling (compiling on a modern Windows version, or by compiling on Linux targeting Windows).

[sivadeilra]

Also, you might check whether you have any anti-virus products installed. If so, try disabling them, or at least adding an exception that covers your development tree. Sometimes "permissions" problems are caused by anti-virus products opening and scanning executable files.

[camelid]

Apparently, Windows 7 is still a Tier 1 target, so even though it's EOL for Microsoft, Rust still has to support it. It seems that maybe we should reduce Windows 7 to a lower tier at some point soon.

[KamilaBorowska]

I would like to point out that according to Firefox Hardware Across the Web report, Windows 7 is used by 23% of Firefox users. Microsoft also offers paid extended security updates through January 2023 for Windows 7 which may be actually used in enterprise environments. I think it's too early to drop support for Windows 7.

That said, this particular issue feels like an issue with anti-virus. @MSxDOS, could you check whether this issue occurs with an antivirus product disabled?

[asaadmohammed74]

I would like to point out that according to Firefox Hardware Across the Web report, Windows 7 is used by 23% of Firefox users. Microsoft also offers paid extended security updates through January 2023 for Windows 7 which may be actually used in enterprise environments. I think it's too early to drop support for Windows 7.

That said, this particular issue feels like an issue with anti-virus. @MSxDOS, could you check whether this issue occurs with an antivirus product disabled?

im having the same issue, i also use windows 7 x64. and don't have any anti virus installed

[MSxDOS]

could you check whether this issue occurs with an antivirus product disabled?

I've already checked and eliminated that from the list of possible causes along with any possible system issues I could think of. The problem appears on two machines with different hardware and software, one of which had a fresh installation of Rust toolchain via rustup and the issue appeared instantly.

There's not much I can draw from that cargo log. By the looks of it the issue happens with crates that depend on and use proc-macro crates. In some cases cargo check doesn't trigger it but cargo build does.

[asaadmohammed74]

using RUSTC_LOG=debug
INFO rustc_codegen_ssa::back::link preparing rlib to "G:\\Development\\rust\\hello_world\\target\\debug\\deps\\libanyhow-a96d4d06084a2ac6.rlib

[apiraino]

@asaadmohammed74 and @MSxDOS just a blind shot, IIUC the error error: failed to build archive: permission denied suggests there's an issue when rustc tries to write on those volumes (F: and G:).

Does the user executing rustc have proper permission to those volumes? Does the error happens intermittently or it is always reproducible?

[tmiasko]

The commit range includes the update of LLVM submodule #80796, so it is probably caused by one of:

• rust-lang/llvm-project@6ec777c
• rust-lang/llvm-project@f684355

[lzybkr]

Permission denied sometimes means another process has an open handle to the file. Process Monitor has been useful to me in tracking down similar issues, which turned out to be an antivirus product in my case.

[FredericaBernkastel]

Downgraded to nightly-2021-01-12, compilation is successful again.

[MSxDOS]

@apiraino There are no issues with permissions on both machines... The error is always reproducible.

[leafinsky-li]

Downgraded to nightly-2021-01-12, compilation is successful again.
I encountered the same problem when upgrading the latest version. After downgrading this version, everything works fine again.

[moxian]

The issue title downplaying the problem a bit.
nightly-2021-01-14 and onward is unable to compile any library crate. I.e. running

rustc +nightly src/lib.rs --crate-type lib

on an empty lib.rs gives the same

error: failed to build archive: permission denied

error: aborting due to previous error

This makes rustc effectively unusable on windows 7. (except for binaries with zero non-proc-macro dependencies)

Here's what's happening, per process monitor:

I am neither windows, nor LLVM expert so i cannot really interpret it, but to transcribe what's happening (judging purely by the names of the winapi calls):

On stable:

• we create the temporary libmain.rlib.temp-archive-6748ddf.a
• write to it
• SetDispositionInformationFile(Delete = False) (??)
• rename it to libmain.rlib

very straightforward

On nightly many more things are happening and i'm not sure why:

• We create the temporary libmain.rlib.temp-archive-d4be097.a
• Open it and immediately close, multiple times with different arguments (??)
• SetDispositionInformationFile(Delete = True) (????) (!!!)
• Write to it
• QueryOpen it, get told that DELETE_PENDING
• give up.

Oh, and @tmiasko implied, but did not explicitly mention, the regression happened in #80960.

[moxian]

(Not sure if i have permission to do this, but..)
@rustbot modify labels: +I-prioritize

[LeSeulArtichaut]

Let's @rustbot ping llvm

[cuviper]

I opened rust-lang/llvm-project#92 to start, a simple revert which reportedly fixes this issue -- #81051 (comment).

[moxian]

I just want to confirm that the fix is in nightly, and it's working!

Thanks, @cuviper!

[klensy]

But while it not applied to beta, it can't build rust with download-ci-llvm = true, as it download beta files from 2021-02-14, or maybe i do something wrong.

[moxian]

Either setting your src/stage0.txt to have

date: 2021-02-28
rustc: nightly

or setting in your config.toml

[build]
rustc = "/path/to/nightly/toolchain/bin/rustc.exe"
cargo = "/path/to/nightly/toolchain/bin/cargo.exe"

should work

P.s.: correction: for some reason src/stage0.txt method does not work for me, but the config.toml does.

Although now that I re-read your message, i'm not sure if download-ci-llvm = true would further impact this. I.e. I don't know if the llvm on ci has the fix commit or not. But then again, download-ci-llvm = true seems to do nothing for me, as in I'm trying to run python x.py build and it's currently rebuilding llvm from source anyway, so..

[cuviper]

I'm not sure how that download is updated, but the PR is beta-nominated, so once that's approved we can backport it to the beta branch and then update master stage0.txt. Hopefully that will sort it out!

[Mark-Simulacrum]

Normally we only do so once a cycle, but we're happy to accept PRs if there's some reason to update it outside of that.

[cuviper]

See #82677 to track long-term resolution between Windows 7 and the reverted bug fix.

[aganea]

Hello! I've fixed the issue in LLVM in llvm/llvm-project@64ab2b6 - please let me know if the issue is still there in the next code drop.

[cuviper]

Thanks @aganea! I don't have access to test this myself, but hopefully the Windows 7 users here can try it out. Let's collect further feedback on the new open issue, #82677.