rustc on Windows gives error when dependencies are on a mapped network drive

[yonran]

When I try to cargo build a project in a mapped network drive in Windows that has at least one dependency, gcc gives error saying it can’t find the dependencies. (In the following example, F:\ is mapped to \vboxsvr\Downloads)

PS F:\hellors> cargo build
   Compiling hellors v0.1.0 (file:///F:/hellors)
error: linking with `gcc` failed: exit code: 1
note: "gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-static-libgcc" "-m64" "-L" "C:\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib" "-o" "F:\hellors\target\debug\hellors.exe" "F:\hellors\target\debug\hellors.o" "-Wl,--gc-sections" "\\?\UNC\vboxsrv\Downloads\hellors\target\debug\deps\liblibc-674726c388d62fa2.rlib" "C:\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib\libstd-4e7c5e5c.rlib" "C:\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib\libcollections-4e7c5e5c.rlib" "C:\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib\librustc_unicode-4e7c5e5c.rlib" "C:\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib\librand-4e7c5e5c.rlib" "C:\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib\liballoc-4e7c5e5c.rlib" "C:\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib\liblibc-4e7c5e5c.rlib" "C:\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib\libcore-4e7c5e5c.rlib" "-L" "F:\hellors\target\debug" "-L" "F:\hellors\target\debug\deps" "-L" "C:\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib" "-L" "F:\hellors\.rust\bin\x86_64-pc-windows-gnu" "-L" "F:\hellors\bin\x86_64-pc-windows-gnu" "-Wl,--whole-archive" "-Wl,-Bstatic" "-Wl,--no-whole-archive" "-Wl,-Bdynamic" "-lws2_32" "-luserenv" "-lcompiler-rt"
note: gcc: error: \\liblibc-674726c388d62fa2.rlib: No such file or directory

Note that gcc was given the path “\?\UNC\vboxsrv\Downloads\hellors\target\debug\deps\liblibc-674726c388d62fa2.rlib” instead of “F:\hellors...”

Compiling a project on a network drive last worked in the 2015-04-29 Windows nightly, and this error started happening on the 2015-05-01 Windows nightly (although you might get the crt2.o/crtbegin.o/crtend.o error instead on some projects from 2015-05-01 to 2015-05-05 #25072).

[alexcrichton]

Yeah this is an unfortunate limitation of running with gcc from MinGW, it appears it just fundamentally doesn't understand all kinds of windows paths (for example the \\?\ syntax you've run into).

This path is introduced from the call to fs::canonicalize and we actually already have some code to fix this case as well.

Out of curiosity, do you know what the non-verbatim path of this looks like? We probably just need to handle another case for fix_windows_verbatim_for_gcc and that should do the trick!

[yonran]

For std::path::Prefix::VerbatimUNC, I think fix_windows_verbatim_for_gcc should convert it to std::path::Prefix::UNC. GCC seems to accept the \\server\share syntax.

I thought that gcc was mangling the \\?\UNC\server\share argument, but after poking around in windbg for a long time and looking at it in ProcessMonitor I realized that it’s not GCC’s fault; it’s msvcrt.dll! For some reason, when you run a command line program built with msvcrt.dll (which new programs are not supposed to link, but mingw does anyway because they don’t want to rewrite the C runtime), msvcrt.dll will scan your verbatim \\?\path\filename args and replace them with useless \\filename strings if the path exists.

For example, if you compile this test program with cl.exe (with the latest C runtime, msvcr120) and run it as echo.exe \\?\C:\Windows\System32\calc.exe, it will output \\?\C:\Windows\System32\calc.exe as expected. But if you compile it with mingw (and the old msvcrt.dll), it will bizarrely output \\calc.exe!

#include <stdio.h>
int main(int argc, char *argv[]) {
    for (int i = 1; i < argc; i++) {
        printf("%s\n", argv[i]);
    }
}

Note: the stack of the call to FindFirstFileA when msvcrt.dll is determining whether to destroy your argument is

00 00000000`0023fca8 00007ff9`f813cc61 KERNELBASE!FindFirstFileA
01 00000000`0023fcb0 00007ff9`f813cd59 msvcrt!find+0x61
02 00000000`0023fce0 00007ff9`f8118293 msvcrt!match+0xa1
03 00000000`0023fd50 00007ff9`f80f0903 msvcrt!cwild+0x45
04 00000000`0023fd80 00007ff9`f80f080c msvcrt!_setargv+0xd6
05 00000000`0023fdc0 00000000`0040116d msvcrt!_getmainargs+0x31
06 00000000`0023fdf0 00007ff9`f80d4e6d image00000000_00400000+0x116d
07 00000000`0023fe30 00000000`00401440 msvcrt!initterm+0x2d
08 00000000`0023fe60 00000000`004014e8 image00000000_00400000+0x1440

I am testing this on Windows 8.1.

[alexcrichton]

Wow, that is some fascinating investigation @yonran! Thanks so much for digging this up!

I've opened a PR to handle this case for now in #25868.