"C://w64devkit-1.21.0/w64devkit/bin/ld.exe: cannot find" the errors happen when compile

[raunyuyuan]

I am using latest version w64devkit-1.21.0. I created a file "hello.c" and its content is:

#include <stdio.h>

int main(void)
{
    puts("Hello, world!");
}

then, I open the cmd, type sh -l cc -o hello.exe hello.c it throws below errors:

C://w64devkit-1.21.0/w64devkit/bin/ld.exe: cannot find C://w64devkit-1.21.0/w64devkit/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/crtbegin.o: No space left on device
C://w64devkit-1.21.0/w64devkit/bin/ld.exe: cannot find -lmingw32: No space left on device
C://w64devkit-1.21.0/w64devkit/bin/ld.exe: cannot find -lgcc: No space left on device
C://w64devkit-1.21.0/w64devkit/bin/ld.exe: cannot find -lmoldname: No space left on device
C://w64devkit-1.21.0/w64devkit/bin/ld.exe: cannot find -lmingwex: No space left on device
C://w64devkit-1.21.0/w64devkit/bin/ld.exe: cannot find -lmsvcrt: No space left on device
C://w64devkit-1.21.0/w64devkit/bin/ld.exe: cannot find -lkernel32: No space left on device
C://w64devkit-1.21.0/w64devkit/bin/ld.exe: cannot find -lpthread: No space left on device
collect2.exe: error: ld returned 1 exit status

[Peter0x44]

Searching for similar issues on stackoverflow, it seems potentially this is windows defender or some sort of antivirus interfering. https://stackoverflow.com/questions/12166606/error-mingw32-bin-ld-exe-final-link-failed-no-space-left-on-device-building-c

I would try confirming theories regarding that first, check if windows defender has any "block history".

[skeeto]

It sounds to me that the explanation in @Peter0x44's link is most likely the cause.

[raunyuyuan]

@Peter0x44 @skeeto I found the reason why that happened. In my case the directory named by Chinese cause this issue. I change the directory name to English solve this.

[skeeto]

Thank you the follow up, @raunyuyuan! That's useful information.

Sorry, I would like w64devkit to better support non-ASCII file names, but some of the included software does not. Binutils supports wide file names, but it apparently produces this bogus error message when given a path mangled by an ASCII-only program.