public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: mizo 91 <mizo91@gmail.com>
To: gcc-help@gcc.gnu.org, LIU Hao <lh_mouse@126.com>
Subject: Re: CreateProcess No such file or directory
Date: Thu, 22 Sep 2022 09:35:21 +0200	[thread overview]
Message-ID: <CAGt5VgHdB_-iBy_3CSnexnu=0uLxV6D=w8c5k96tDawFw7oUnA@mail.gmail.com> (raw)
In-Reply-To: <a76c146a-191a-2683-fe9e-14dd3ec0ba02@126.com>

[-- Attachment #1: Type: text/plain, Size: 2952 bytes --]

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
>

  reply	other threads:[~2022-09-22  7:35 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-20 16:02 mizo 91
2022-09-20 16:18 ` Richard Earnshaw
2022-09-20 17:17   ` mizo 91
2022-09-20 22:27     ` Tamar Christina
2022-09-21  2:42       ` fedor_qd
2022-09-21 15:27         ` mizo 91
2022-09-21 15:41           ` Tom Kacvinsky
2022-09-26  6:58           ` Re[2]: " fedor_qd
2022-09-22  6:44 ` LIU Hao
2022-09-22  7:35   ` mizo 91 [this message]
2022-09-22  9:46     ` LIU Hao
2022-09-22 14:55       ` mizo 91
2022-09-22 16:04         ` LIU Hao
2022-09-22 16:50           ` mizo 91
2022-09-23 17:40             ` Xi Ruoyao
2022-09-23 21:11               ` mizo 91
2022-09-24  5:13                 ` Xi Ruoyao
2022-09-24  9:28                   ` mizo 91
2022-09-24  9:51                     ` Xi Ruoyao
2022-09-24 10:20                       ` Jonathan Wakely
2022-09-23 17:14         ` David Brown
2022-09-23 20:55           ` mizo 91
2022-09-22  8:19   ` Jonathan Wakely
2022-09-22  8:42     ` Jonathan Wakely
2022-09-22  9:48       ` LIU Hao
2022-09-22  9:50       ` mizo 91

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGt5VgHdB_-iBy_3CSnexnu=0uLxV6D=w8c5k96tDawFw7oUnA@mail.gmail.com' \
    --to=mizo91@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=lh_mouse@126.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).