@response_file issue: gcc.exe: fatal error: cannot execute 'as.exe': CreateProcess: No such file or directory

[fskoras]

Hi there,

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.

The weirdly glued path to 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 includes.txt

On linux this is not the problem. 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?

[niXman]

hi,

sorry, I have no ideas...

I think be better to post this question to the gcc mailing list: [email protected]

[fskoras]

Thanks for the quick response

I just assumed that because its only happening on Windows its more MinGW problem than gcc? I'm not sure who is responsible for MinGW maintanance/development but it shouldn't hurt to try. Thanks for the mail :)

[niXman]

I just assumed that because its only happening on Windows its more MinGW problem than gcc?

I think yes, but my thought was that the GCC developers know the code better and will be able to suggest the "direction".

[niXman]

Thanks for the mail

please post the question there...

[fskoras]

Thanks for the mail

please post the question there...

I did. Do You want to wait for their response or shall i close the issues now?

[niXman]

Do You want to wait for their response or shall i close the issues now?

no, leave it open please.

[fskoras]

I recieved some feedback from MinGW developers. Unfortunatly they don't see this as a bug but rather operating system limitaiton. There was one bug entry created by Jonathan Wakely but its only related to how gcc is handling error message which is misleading: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107007

If youre interested you can follow the thread here: https://gcc.gnu.org/pipermail/gcc-help/2022-September/141889.html

[niXman]

I have already seen that conversation, thank you!

[niXman]

please leave this issue open, just in case...

[fskoras]

I managed to fix my problem

I used -Wp, option to pass @includes.txt response file directly to Preprocessor (It worked well even on older compiler versions like 4.8.5).

Apparently -I are also passed to subroutines like Assembler or Linker. This behavior is hidden in the official gcc documentation and in my case it wasn't necessary at all. I just wanted to pass include directories to Preprocessor. I think this is another great example of how hidden(implicit) rules lead to nasty problems.

Anyway, I hope this helps someone.

Final compilation command looks like this: gcc -Wp,@includes.txt main.c

[fskoras]

Hi There,

Been a while :)

There is a chance this will be fixed in the next release: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=180ebb8a24d24fc5b105f2257d6216f6dfde62df

Found in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45749