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

Gyan Doshi ffmpeg at gyani.pro
Tue Mar 18 12:04:26 EET 2025



On 2025-03-18 03:27 pm, Martin Storsjö wrote:
> 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.

I'll push this now, and then work on a robust check.

Regards,
Gyan



More information about the ffmpeg-devel mailing list