1.29 fails to build on a Windows networked drive

[mark-summerfield]

I have a program that builds under 1.28 on Linux and Windows with no errors or warnings.
The same program builds under 1.29 on Linux, but won't build on Windows if the source is on a virtuabox (i.e., networked) drive.

See my initial report here: https://users.rust-lang.org/t/rust-1-29-0-is-out/20400/10?u=mark
And the Cargo.toml and src/main.rs here: https://users.rust-lang.org/t/rust-1-29-0-is-out/20400/20?u=mark

[cuviper]

Just for quick context, the failure looks like:

LLVM ERROR: IO failure on output stream: bad file descriptor

I suggested a workaround to set CARGO_TARGET_DIR to a local drive, leaving the source still on the virtualbox drive, and @mark-summerfield reported that this worked.

[yrashk]

I can confirm that I have the same issue with 1.29.1, with the same scenario of a mapped virtual drive.

[retep998]

Would be helpful if someone could bisect to find the exact nightly where this was broken. I suspect it is an LLVM update due to the error coming from LLVM.

[neoeinstein]

I just ran into this issue as well. I'm running in Parallels on MacOS, building a binary for Windows. The source resides on a mapped network drive that Parallels attaches to the instance. Using the workaround of setting CARGO_TARGET_DIR to a folder on a local drive worked for me.

[kennytm]

The error is reproducible by simply creating an empty project and add a dependency, then cargo build it.

cargo new --lib a
cd a
echo cfg-if = "*" >> Cargo.toml
cargo build

Edit: Also happens when compiling with rustc --crate-type lib.

Bisection:

Nightly	Compiles?
nightly-2018-06-20	✓
nightly-2018-08-02	✗
nightly-2018-07-11	✓
nightly-2018-07-22	✗
nightly-2018-07-16	✗
nightly-2018-07-13	✗

(No nightlies on 2018-07-12)

The error is introduced between e5f6498...64f7de9, which does include #51966 (Upgrade to LLVM's master branch (LLVM 7)).

[adamski]

I just hit this issue, building under Windows 10 running on Parallels with the source project in a Mac folder. On Rust 1.38.0, default install from rustup-init

[mark-summerfield]

My workaround is to create C:\tmp\targets and for each project have a prepare.bat containing:

SET CARGO_TARGET_DIR=C:\tmp\targets\_myproject_
mkdir %CARGO_TARGET_DIR%

And to run this once per session before using Rust.

[adamski]

@mark-summerfield I am using CMake (via CMakeRust) to build the project (which contains C++ code too), and was able to set the CARGO_TARGET_DIR there.

[AurumTheEnd]

Currently having the same issue - project is on VirtualBox's shared drive. The project, when copied onto a non-network path in the VM, builds normally.

[adamski]

I solved this by pulling the repo on the Windows machine. Has a positive side-effect that it ensures that people compiling on Windows will get everything they need to build the project.

[AurumTheEnd]

I solved this by pulling the repo on the Windows machine.

Even if you pull it onto the shared drive? If yes, then I wonder if it would cause problems on the other side or if Linux would miraculously deal with it :D
Regardless, will try this out in the near future. Thanks for the tip.

[adamski]

No, not the shared drive. On the local folder of the VM

[cuviper]

There was a change in LLVM that might have fixed this, but we had to revert for Windows 7's sake. Copying from #82677:

That change was meant to fix LLVM PR42623, which also references Rust #54216. It would be nice if some Windows user could verify if that was fixed on a nightly where we still had the change, roughly 2021-01-13 through 2021-02-28. But since it left Windows 7 unable to create any archives, we decided that regression was worse than the fix.