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@foss.arm.com>
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.
>