I was very lucky and never see that error before. 11.2.0 has same error too. -- Sent from Outlook Email App for Android серада, 21 верасня 2022, 06:27PM +03:00 from mizo 91 mizo91@xxxxxxxxx : >@Tamar.Christina >I have created public repository on github and placed 'procmon' log file there: >https://github.com/fskoras/CreateProcess-gcc-issue/blob/master/Logfile.CSV >You can also clone the repository if you want to try to recreate the issue: >https://github.com/fskoras/CreateProcess-gcc-issue >I have executed the as.exe directly and it worked without problems: >D:/Tools/x86_64-12.2.0-release-win32-seh-rt_v10-rev0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/as.exe --version >GNU assembler (GNU Binutils) 2.38 >Copyright (C) 2022 Free Software Foundation, Inc. >This program is free software; you may redistribute it under the terms of >the GNU General Public License version 3 or later. >This program has absolutely no warranty. >This assembler was configured for a target of `x86_64-w64-mingw32'. >@fedor_qd >I have checked version 11.2.0 and the same problem occurs > >binutils version used for both versions: >gcc x86_64-11.2.0: GNU assembler (GNU Binutils) 2.37 >gcc x86_64-12.2.0: GNU assembler (GNU Binutils) 2.38 > >R. > > >śr., 21 wrz 2022 o 04:42 < fedor_qd@xxxxxxx> napisał(a): >>I saw such error in my build gcc 12.1.0 for Symbian. GCC 11.2.0 works fine. >>I encounter such error while building ScummVM for Symbian. This error happened randomly. I thought my environment broken and switched to GCC 11.2.0 and errors gone. >>GCC 11.2.0 comes with binutils 2.35, GCC 12.1.0 comes with binutils 2.29.1 >>What binutils version you have? >>-- >>Sent from Outlook Email App for Android серада, 21 верасня 2022, 01:29AM +03:00 from Tamar Christina via Gcc-help gcc-help@xxxxxxxxxxx : >> >>>We'd mostly be guessing here, use strace or https://learn.microsoft.com/en-us/sysinternals/downloads/procmon to see which path is actually being accessed and why it failed. >>> >>>Also check that you can run `as` correctly. This error can also happen if a dependency of `as.exe` isn't found during loading. >>> >>>Cheers, >>>Tamar >>> > -----Original Message----- > From: Gcc-help < gcc-help-bounces+tamar.christina=arm.com@xxxxxxxxxxx> > On Behalf Of mizo 91 via Gcc-help > Sent: Tuesday, September 20, 2022 1:17 PM > To: Richard Earnshaw < Richard.Earnshaw@xxxxxxxxxxxx> > Cc: gcc-help@xxxxxxxxxxx > Subject: Re: CreateProcess No such file or directory > > According to Microsoft docs path length limitation for windows is 256. In my > case its 143 chars. I think the problem might be related to how gcc driver is > passing along unmarshalled arguments to its subprograms like as.exe. > Suprisingly this works correctly if I enforce gcc driver to use preprocessor only > by adding -E flag > > btw. I failed to previously mention that I'm using Mingw-W64 version > provided kindly by niXman Binaries taken directly from official MinGW-W64 > builds: > https://www.mingw-w64.org/downloads/#mingw-builds > https://github.com/niXman/mingw-builds-binaries/releases > > R. > > wt., 20 wrz 2022 o 18:18 Richard Earnshaw >< Richard.Earnshaw@xxxxxxxxxxxx> > napisał(a): > >> >> >> On 20/09/2022 17:02, mizo 91 via Gcc-help wrote: >>> Hello, >>> >>> I'm having trouble compiling simple test program on windows 10 with >>> long list of includes provided via '@response_file' argument >>> >>> The full error is: >>> >>> gcc.exe: fatal error: cannot execute >>> >> 'C:/Tools/x86_64-12.2.0-release-win32-seh-rt_v10- > rev0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64- > w64-mingw32/bin/as.exe': >>> CreateProcess: No such file or directory >>> >>> compilation terminated. >>> >>> Above path to the assembler program is valid therefore I don't >>> understand what is the issue here? >>> >>> You can try to recreate the problem by compiling simple main.c file >>> with nothing in it but main function using command: >>> gcc @includes.txt main.c >>> >>> I assume it has something to do with windows 32k CreateProcess >>> command length limitation? But isn't that the reason why respone >>> files were invented? >>> >>> Regards, >>> Filip >> >> I'm by no means a windows expert, but I wonder if this might be >> related to the length of the path to the assembler and that it's >> somehow getting truncated. >> >> R. >>