If I compile with: g++ -std=c++11 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 [my working directory can be a UNC path in PowerShell]). Unfortunately, mapping to a drive letter also does not work: g++ -std=c++11 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 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 drives just fine. Here's the gcc version info of the version with the issue: gcc.exe -v Using built-in specs. COLLECT_GCC=C:\MinGW64_cpp17\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw64_cpp17/bin/../libexec/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper.exe OFFLOAD_TARGET_NAMES=nvptx-none Target: x86_64-w64-mingw32 Configured with: ../configure --prefix=/r/winlibs64_stage/11532.gcc/inst_gcc-12.2.0/share/gcc --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders' --with-tune=generic --enable-checking=release --enable-threads=posix --disable-sjlj-exceptions --disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap --enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath --disable-libstdcxx-debug --disable-version-specific-runtime-libs --with-stabs --disable-symvers --enable-languages=c,c++,fortran,lto,objc,obj-c++,jit --disable-gold --disable-nls --disable-stage1-checking --disable-win32-registry --disable-multilib --enable-ld --enable-libquadmath --enable-libada --enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string --enable-libgomp --enable-graphite --enable-mingw-wildcard --enable-libstdcxx-time --disable-libstdcxx-pch --with-mpc=/d/Prog/winlibs64_stage/custombuilt --with-mpfr=/d/Prog/winlibs64_stage/custombuilt --with-gmp=/d/Prog/winlibs64_stage/custombuilt --with-isl=/d/Prog/winlibs64_stage/custombuilt --enable-libstdcxx-backtrace --enable-install-libiberty --enable-__cxa_atexit --without-included-gettext --with-diagnostics-color=auto --enable-clocale=generic --with-libiconv --with-system-zlib --with-build-sysroot=/r/winlibs64_stage/11532.gcc/gcc-12.2.0/build_mingw/mingw-w64 CFLAGS='-I/d/Prog/winlibs64_stage/custombuilt/include/libdl-win32 -D__USE_MINGW_ACCESS' CXXFLAGS=-D__USE_MINGW_ACCESS LDFLAGS='-Wl,--disable-nxcompat -Wl,--disable-high-entropy-va -Wl,--disable-dynamicbase' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders) Here's the old build from 2018 where this isn't an issue: gcc.exe -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)
> g++ -std=c++11 iterate.cpp -o "Z:\28sec\out.exe" Does `g++ -c -std=c++11 iterate.cpp -o "\\machine_name\d\performance testing\t.o" ` work? Also if it is failing like this, it is not a problem with GCC rather than mingw.
(In reply to Andrew Pinski from comment #1) > > g++ -std=c++11 iterate.cpp -o "Z:\28sec\out.exe" > > > Does `g++ -c -std=c++11 iterate.cpp -o "\\machine_name\d\performance > testing\t.o" ` work? > > Also if it is failing like this, it is not a problem with GCC rather than > mingw. Here's what I got: ``` g++ -c -std=c++11 iterate.cpp -o "\\the-warpstar\d\perfor mance testing\t.o" Assembler messages: Fatal error: can't create \\machine_name\d\performance testing\t.o: Invalid argument ``` Same if I use the mapped drive letter Z. The mingw people told me to come here. https://github.com/brechtsanders/winlibs_mingw/issues/112 Should I go back to them? I'm confused with whom the issue actually lies.
Please ignore the different machine names in the output I posted above, I forgot to change it in both appearances. I attempted to change it to "machine_name" to avoid confusion but missed it in one spot and I don't know how to edit comments.
Try the following: g++ -std=c++11 iterate.cpp S -o "Z:\28sec\out.s" If this works, then you should report it to binutils. Though I suspect it is https://sourceware.org/bugzilla/show_bug.cgi?id=25713 which was only fixed earlier in the year.
(In reply to Andrew Pinski from comment #4) > Try the following: > g++ -std=c++11 iterate.cpp S -o "Z:\28sec\out.s" > > If this works, then you should report it to binutils. > Though I suspect it is https://sourceware.org/bugzilla/show_bug.cgi?id=25713 > which was only fixed earlier in the year. Unfortunately it did not work. Here's what I got: ``` g++ -std=c++11 iterate.cpp S -o "Z:\28sec\out.s" 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.s: No such file or directory collect2.exe: error: ld returned 1 exit status ``` Any suggestions for what I should do now?
I had a typo, it should have been -S rather than just S.
I can confirm it works with the -S flag. Version of binutils is 2.39, so indeed something ma be broken since 2.38.
So this is not a GCC bug, report it to binutils. though as I mentioned I think it was part of https://sourceware.org/bugzilla/show_bug.cgi?id=25713 which is causing the issue.