在 2022/9/21 00:02, mizo 91 via Gcc-help 写道: > Hello, > > I'm having trouble compiling simple test program on windows 10 with long > list of includes provided via '@response_file' argument > > Greetings. mingw-w64 developer speaking. As far as I can see, there are at least two issues about your report: The first, obvious issue is that the error message is incorrect. The reason for that is, if we take a look at 'libiberty/pex-win32.c' we see the following: 853 /* Create the child process. */ 854 pid = win32_spawn (executable, (flags & PEX_SEARCH) != 0, 855 argv, env, dwCreationFlags, &si, &pi); 856 if (pid == (pid_t) -1) 857 pid = spawn_script (executable, argv, env, dwCreationFlags, 858 &si, &pi); 859 if (pid == (pid_t) -1) 860 { 861 *err = ENOENT; 862 *errmsg = "CreateProcess"; 863 } We also notice this is the only place where `"CreateProcess"` appears as a sole part of an error message. The cause of this issue is apparent: libiberty tries `win32_spawn`, and if for whatever reason it fails, it makes another attempt with `spawn_script`, and if it fails again, `*err` is always set to `ENOENT` i.e. `No such file or directory`, no matter why. Since we are invoking 'as.exe' here, which is never a script, the first attempt must have failed. We can start 'gcc.exe' with a debugger. There are actually two calls to `CreateProcessA()`: one to 'cc1.exe' and the other to 'as.exe'; the latter fails with `ERROR_INVALID_PARAMETER`. So, the error happens, not because anything can't be found, but because the command line is too long. With your example, it contains a lot of `-include` arguments and takes ~44K characters, and is not valid. Windows only allows a single command line up to 32,767 characters, because the NT syscall uses a 16-bit length for a UTF-16 string which includes a null terminator. -- Best regards, LIU Hao