Hello LIU Hao,

Thank you for your insight. In my understanding main purpouse of response
file is to overcome command too long issue(which can also happen on linux
but is by magnitude less likely). I imagine if my command is too long gcc
driver should ensure that subprograms like assembler should have recieved
command arguments in the same way gcc did (which is through response file).
Insted the assembler process is spawned directly By CreateProcessA whith
unwrapped arguments by the driver which is like you said the reason for the
error. Additionaly isnt -I flags required for preprocessor only? Why gcc is
trying to pass -I arguments to assembler program? Wouldnt you consider this
gcc driver bug than?

Kind Regards,
Filip

czw., 22 wrz 2022 o 08:44 LIU Hao <lh_mouse@126.com> napisał(a):

> 在 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
>