Cannot Compile EXE on Shared Network Drive

[JohnTravolski]

If I compile with:

g++ -std=c++17 iterate.cpp -o "\\machine_name\d\performance testing\out.exe"

I get this output and no .exe file:

c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot open output file \\machine_name\d\performance testing\out.exe: Invalid argument collect2.exe: error: ld returned 1 exit status

If I change the output path to a system drive rather than one on the network, it compiles fine. It gives the same error if I use a local, rather than absolute, path as well (and have the working directory on the network drive).

[brechtsanders]

It looks like UNC paths don't work. I have seen similar issues with GDB too.

If you map a network drive and use the drive letter instead, does it work then?

How van your working directory be an UNC path? Windows doesn't allow this.

Have you reported this issue to the GCC team (see https://gcc.gnu.org/bugs/)?

[JohnTravolski]

Unfortunately, no, mapping to a drive letter does not work:
g++ -std=c++17 iterate.cpp -o "Z:\28sec\out.exe"
gives
c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot open output file Z:\28sec\out.exe: No such file or directory collect2.exe: error: ld returned 1 exit status

My working directory can be a UNC path in PowerShell. See here:

I am not sure if this is relevant, but I have a much older version of MinGW from Winbuilds (I installed from win-builds-1.5.0.exe sometime back in 2018), and it is able to output the compiled exe directly to network shares just fine. Here's that old version's information if interested:

PS C:\MinGW> gcc -v
Reading specs from c:/mingw/bin/../lib64/gcc/x86_64-w64-mingw32/4.8.3/specs
COLLECT_GCC=C:\MingW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.3/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.8.3/configure --prefix=/opt/windows_64 --with-sysroot=/opt/windows_64 --libdir=/opt/windows_64/lib64 --mandir=/opt/windows_64/man --infodir=/opt/windows_64/info --enable-shared --disable-bootstrap --disable-multilib --enable-threads=posix --enable-languages=c,c++ --enable-checking=release --enable-libgomp --with-system-zlib --with-python-dir=/lib64/python2.7/site-packages --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --with-gnu-ld --verbose --enable-java-home --with-java-home=/opt/windows_64/lib64/jvm/jre --with-jvm-root-dir=/opt/windows_64/lib64/jvm --with-jvm-jar-dir=/opt/windows_64/lib64/jvm/jvm-exports --with-arch-directory=amd64 --with-antlr-jar='/home/adrien/projects/win-builds-1.5/slackware64-current/d/gcc/antlr-*.jar' --disable-java-awt --disable-gtktest --build=x86_64-slackware-linux --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
Thread model: posix
gcc version 4.8.3 (GCC)

I have not reported to the GCC team, but I will soon.

[JohnTravolski]

They said it's a bug on the MinGW side of things:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106728
Is this the wrong place to report it?
Edit:
Maybe it's not, still working through it. I'm not sure yet.

[brechtsanders]

I can reproduce your issue with GCC 12.2.0.

This works with GCC 12.1.0:

D:\>D:\Prog\winlibs64-12.1.0msvcrt\mingw64\bin\gcc -c -o \\SERVER\Users\brecht\test.o \\SERVER\Users\brecht\test.c

Same thing fazls with GCC 12.2.0:

D:\>D:\Prog\winlibs64-12.2.0msvcrt\mingw64\bin\gcc -c -o \\SERVER\Users\brecht\test.o \\SERVER\Users\brecht\test.c
Assembler messages:
Fatal error: can't create \\SERVER\Users\brecht\test.o: Invalid argument

With -S flag as proposed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106728 it does work though:

D:\>D:\Prog\winlibs64-12.2.0msvcrt\mingw64\bin\gcc -c -o \\SERVER\Users\brecht\test.o \\SERVER\Users\brecht\test.c -S

And it's true: binutils is a newer version, so the issue may be in there.

[brechtsanders]

I think I found it.

Through patches in the context of https://sourceware.org/bugzilla/show_bug.cgi?id=25713 changes were made to the function _bfd_real_fopen() in bfd/bfdio.c to add the \\?\ prefix to the path as this allows for paths with unlimited lengths.

However, according to https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry the \\?\ prefix is only for absolute paths, and can't be used for relative paths or paths containing . or .. as references to the current/parent directory. Furthermore UNC paths (which we have issues with) should not just have \\?\ prepended. Instead e.g. \\server\share becomes \\?\UNC\server\share.

So additional code is needed to fix bfd/bfdio.c...

As a proof of concept I added this before #elif defined (_WIN32) in bfd/bfdio.c:

#elif defined (__MINGW32__xxx)
   FILE *     file = fopen (filename, modes);
   return close_on_exec (file);

and that fixed the problem for me (but obviously will have the maximum path length limit again).

[brechtsanders]

I just made a new release with the above change to binutils. Can you confirm that release works for you with UNC paths?

[brechtsanders]

Bug reported at binutils: https://sourceware.org/bugzilla/show_bug.cgi?id=29533

[brechtsanders]

I tried the following with the latest release and got no issues:

echo "int main () { return 0; }" > '\\servername\share\hello.cpp'
g++ -std=c++17 '\\servername\share\hello.cpp' -o '\\servername\share\hello.exe'
'\\servername\share\hello.exe'