On Mon, 8 Jun 2026, OKA Motofumi via ffmpeg-devel wrote:
Passing a very large number of objects directly to ar can sometimes cause an 'Argument list too long' error. --- compat/windows/makedef | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/compat/windows/makedef b/compat/windows/makedef index af42f08fd5..963f2b5b55 100755 --- a/compat/windows/makedef +++ b/compat/windows/makedef @@ -46,7 +46,9 @@ libname=$(mktemp -u "library").lib trap 'rm -f -- $libname' EXIT
if [ -n "$AR" ]; then - $AR rcs ${libname} $@ >/dev/null + echo "rcs ${libname} $@" > ${libname}.args + $AR @${libname}.args > /dev/null + rm -f ${libname}.args
If we were to go with this kind of change, I think it would be nicer to only add the list of object files to the response file, and keep the other options ("rcs ${libname}") to be passed directly - that keeps the invocation a bit clearer, and makes it more similar to the existing use of response files for invoking the linker, since 9e857e1f8aeeb655adb9d09bf53add26a27092e2. However - the "echo" command in shells can't cope with unlimited command line lengths in all shells; in busybox-w32 it is limited to 32k, like in any native Windows process invocation. I posted https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/23591 which avoids the issue in a different way, by reusing the response file generated by make within makedef too. // Martin