From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 89D9D3857BB3 for ; Thu, 22 Sep 2022 07:35:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 89D9D3857BB3 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x634.google.com with SMTP id u9so19107624ejy.5 for ; Thu, 22 Sep 2022 00:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date; bh=z/Xv2N9qGQODnhmawPAZVXnrwO63XSGB3iTt2zeYvYA=; b=gdfOF93fwihQ5Vy22FN+I4Ez7vCpAeq0YIymBL6LYdpwmggFWLzBY9INvQom9VaZcf MsBH959sNWq7XWoRE0D67ncF/nYtygoojl4tFZYp10GQ/Z8bF8ltTHIM/Sscg8nm9Is6 nZsIODh8ZyyRj3Ls6g4yKWaSVoYvgwgbVM0bOpGEOs2SXsAuuk94CYVghWWOO5SMYNm7 TCwqDv5QQ8odP9hzmAe8PYRrdvC3m/xbv3Ka8Pacx2x4hlIaFAE52j5cxyrTh4Mb6FCw JP+3VsacknJ+/Q21a77ZWBwEWuQF8q3kK/Vb4XYP15pl3QELZM1nVXL87jguYZFcGz/B nCjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=z/Xv2N9qGQODnhmawPAZVXnrwO63XSGB3iTt2zeYvYA=; b=4TPEMzIrhyPRWn3TOoRjzG0VY8J8B3/M55AxY+buvlw698Mjr9x859cq/rznIQy5Yc Fkt2kTSgWcQNL0g5VLMzuVuPBRR0+rl+TZZqd4C0ldSDjwvleIhkWzXzsbF8UiSDFJZ6 MFRBbPdhYg+NezexXUqlaPRsNug25BYddhVE2t3KCurixNn+FzsBFcNcD4LMFRzI64HI K83fPOLtoZzc8RgvHQI1tQMvaAxUqP210PQ8/js+ERL/wyNcYRm+xevx6NyOKVi/+7i1 gvPSYvVuqEjdK2FS47tHAHEzAqlPYwz/oHBxxg8gPnnDjvDsY4XzmMpKa61dgAoi4prf cD9w== X-Gm-Message-State: ACrzQf1hWBcw4ZYkqYNk1grV1HeCoOCVT6PmnP3lt0GHrGr35j85rYH1 FWw9tsdkMizJJcVIKtUuTFwukRZ6XBa642mzN2yJDuEiwEU= X-Google-Smtp-Source: AMsMyM7W/jEDNNiJ0ojwe5fWvU3M7TmB09ET7axn738iwA5GxmdUzZ0/7PvkXh7o0s3oUDEsA1XxB6j6DzQ17EmzeIU= X-Received: by 2002:a17:907:1623:b0:77e:9455:b4d9 with SMTP id hb35-20020a170907162300b0077e9455b4d9mr1538419ejc.491.1663832133093; Thu, 22 Sep 2022 00:35:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: mizo 91 Date: Thu, 22 Sep 2022 09:35:21 +0200 Message-ID: Subject: Re: CreateProcess No such file or directory To: gcc-help@gcc.gnu.org, LIU Hao Content-Type: multipart/alternative; boundary="000000000000424dfd05e93f1b17" X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000424dfd05e93f1b17 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 napisa=C5=82(a): > =E5=9C=A8 2022/9/21 00:02, mizo 91 via Gcc-help =E5=86=99=E9=81=93: > > 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 =3D win32_spawn (executable, (flags & PEX_SEARCH) !=3D 0, > 855 argv, env, dwCreationFlags, &si, &pi); > 856 if (pid =3D=3D (pid_t) -1) > 857 pid =3D spawn_script (executable, argv, env, dwCreationFlags, > 858 &si, &pi); > 859 if (pid =3D=3D (pid_t) -1) > 860 { > 861 *err =3D ENOENT; > 862 *errmsg =3D "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 > --000000000000424dfd05e93f1b17--