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

[Martin Storsjö]

On Thu, 20 Mar 2025, Ramiro Polla wrote:

> On Tue, Mar 18, 2025 at 11:06 AM Gyan Doshi <git at videolan.org> wrote:
>>
>> ffmpeg | branch: master | Gyan Doshi <ffmpeg at gyani.pro> | Mon Mar 17 20:57:28 2025 +0530| [740d4009656abeb006e2d43001b59d875c1a7a6a] | committer: Gyan Doshi
>>
>> ffbuild: use response files only if ar accepts them
>
> Sorry to come in late to the discussion...
>
> I'm not a big fan of response files, because they make troubleshooting
> more annoying (I like copying the command that failed and running it
> again on its own with all arguments).

Fair enough, I can resonate with that argument.

> IMO this shouldn't be the default, but only used on systems where this 
> could be a problem (i.e.: Windows). Also, only based on host systems, so 
> not while cross-compiling from Linux.

Yes, maybe. However there are a couple more cases that muddies the 
distinction.

If building with Windows tools from within WSL (e.g. if building with MSVC 
this way), then the host system, from within configure and make, looks 
like a unix, while the build tools actually still have the same 
limitation.

The same issue also potentially arises if you build with msvc-wine (MSVC, 
wrapped in scripts with wine).

Not sure what the best distinction here would be? If the toolchain is MSVC 
or if the host OS is windows?

> I was wondering why ld.exe/ar.exe fail with a long argument list, but
> echo doesn't. After a bit of investigation, it seems that cygwin/msys2
> pass arguments through STARTUPINFO::lpReserved2 and shared memory. But
> only programs built for cygwin/msys2 can make use of that, otherwise
> the parameters from CreateProcess() are used. So echo is a
> cygwin/msys2 program, but ld.exe/ar.exe are not. If, by any chance,
> you have a non-cygwin/msys2 echo.exe on your path, this will fail
> again.

Yes, this does rely on that assumption. (I did bring this up in early 
review and asked Gyan investigate to make sure this really is the case, so 
we don't just gain the extra command line space of the linker options). I 
don't see it as a very high risk right now though.

>> @@ -68,8 +72,12 @@ $(SUBDIR)$(SLIBNAME): $(SUBDIR)$(SLIBNAME_WITH_MAJOR)
>>
>>  $(SUBDIR)$(SLIBNAME_WITH_MAJOR): $(OBJS) $(SHLIBOBJS) $(SLIBOBJS) $(SUBDIR)lib$(NAME).ver
>>         $(SLIB_CREATE_DEF_CMD)
>> +ifeq ($(AR_OBJS),true)
>>         $(Q)echo $$(filter %.o,$$^) > $$@.objs
>>         $$(LD) $(SHFLAGS) $(LDFLAGS) $(LDSOFLAGS) $$(LD_O) @$$@.objs $(FFEXTRALIBS)
>> +else
>> +       $$(LD) $(SHFLAGS) $(LDFLAGS) $(LDSOFLAGS) $$(LD_O) $$(filter %.o,$$^) $(FFEXTRALIBS)
>> +endif
>>         $(SLIB_EXTRA_CMD)
>>         -$(RM) $$@.objs
>
> Is there any reason why we don't ifeq the removal of the response file as well?

I guess that could be done, but it makes the code a little bit more messy 
with even more ifdefs, so I'm not sure if it's worth it?

// Martin