在 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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature