[FFmpeg-devel] [PATCH] ffbuild: use response files only if ar accepts them

Martin Storsjö martin at martin.st
Tue Mar 18 11:57:15 EET 2025


On Mon, 17 Mar 2025, Gyan Doshi wrote:

>
>
> On 2025-03-17 09:44 pm, Zhao Zhili wrote:
>> 
>>> On Mar 17, 2025, at 23:16, Gyan Doshi <ffmpeg at gyani.pro> wrote:
>>> 
>>> This is to not break linking with toolchains that don't support reading
>>> args from a 'response file'.
>>> ---
>>> I've assumed that ld on a system will have same support as ar.
>>> 
>>> configure           | 7 +++++++
>>> ffbuild/library.mak | 8 ++++++++
>>> 2 files changed, 15 insertions(+)
>>> 
>>> diff --git a/configure b/configure
>>> index f6964c4ee1..d84e32196d 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -5230,6 +5230,12 @@ else
>>>      ar_o='$@'
>>> fi
>>> 
>>> +if $ar 2>&1 | grep -qi  "@.*file"; then
>>> +    ar_objs="true"
>>> +else
>>> +    ar_objs=""
>>> +fi
>> Works for me.
>
> Good. Let's wait for another report.

This unbreaks the build for me on macOS too.

As this change did break a fairly major platform, I don't think we should 
wait too long to either revert the change, or push the fix.

As for the fix - I generally find it more robust to actually _try_ doing 
the requested thing (use a response file), than to look for specific 
strings in help output.

I see that the regex, "@.*file", should be matched by both GNU ar and 
llvm-ar, so that's good. But e.g. MS lib.exe also supports response files, 
and it doesn't include this pattern in the output. Also MS lib.exe would 
certainly be a case where we'd want to use response files to overcome the 
command line length limit.

So TL;DR, please push this to unbreak platforms like macOS and BSD, or 
revert the original change. But I don't find the test entirely ideal.

// Martin



More information about the ffmpeg-devel mailing list