https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #13 from Costas Argyris <costas.argyris at gmail dot com> ---
(In reply to John Soo from comment #12)
> I think the general problem in that issue is that ARG_MAX is not respected
> when the driver (or any subprocess) execs things on linux. I think that it
> is not the same as the original issue here, though.
> 
> > I don't know if its going to be helpful to see that patch as a guide
> 
> Do you think using response files like in pex-win32.c in pex-unix.c could
> help? I tried this out and it seems like this may not solve all the ARG_MAX
> problems.

I really don't know because the problem might be happening even before it gets
to the point where the new subprocess is spawned.    Then, passing the command
line through a response file wouldn't help with anything, if the problem has
already happened by that point.

The Windows patch above just checks if the subprocess is about to be spawned
with a command line > 32K and if that is true it simply puts it in a temporary
response file and calls the subprocess with @rsp as the only arg, instead of
the large command line which would break it.    But obviously this makes the
assumption that the large command line is correct (nothing has been dropped or
otherwise messed up).

Here though it seems that you are dealing with another sort of limit which is
much larger (I have seen 128K being mentioned on the GH page).    If this
somehow corrupts the command line, it wouldn't help if that command line went
into a response file because it would still be wrong.    To my knowledge,
Linux-based systems don't have a command line length limitation, so I can't see
how a response file approach would be useful at the point where the subprocess
is spawned.    Whether something similar can be used at an earlier point to
save it from the 128K limit, whatever it is, is unknown to me.

Reply via email to