Open RomainMuller opened 2 hours ago
Related Issues and Documentation
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
As suggested by @gabyhelp, this is actually very much related to (although this has the added characteristic of being an apparent -toolexec
break out of the response file feature):
Also, the culprit is likely this code path:
Since in our case, the prog
ends up being the -toolexec
executable...
Go version
go version go1.23.2 linux/arm64
Output of
go env
in your module/workspace:What did you do?
The following command works as intended:
However if you use any
-toolexec
value, it suddenly fails on Windows:This is because the
github.com/elastic/go-elasticsearch/v8/typedapi/types
package contains a metric ton of files, and results in an excessively long command line for Windows.What did you see happen?
What we observe is that when there is no
-toolexec
the Windows arguments size limit (of 32KiB) is "worked around" by passing an@args-file
value that contains all the arguments instead of passing the arguments list itself directly...Unfortunately, the use of
-toolexec
appears to disable this mechanism, making it impossible to build packages with very large amounts of files in them on Windows.I have verified this behavior using
strace
on a Linux machine... I expect the same behavior happens on Windows as well and explains our issue here...What did you expect to see?
I expect a package that successfully builds without
-toolexec
to also be build-able with-toolexec
, and for the-toolexec
tool to actually also receive the arguments file stand-in when appropriate.