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
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
