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.