[FFmpeg-devel] [PATCH] ffbuild: read library linker objects from a file
Martin Storsjö
martin at martin.st
Wed Mar 12 09:59:05 EET 2025
On Wed, 12 Mar 2025, Gyan Doshi wrote:
> The linker command can exceed the maximum argument limit on MinGW,
> especially for libavcodec.
>
> The objects list is now stored in a file and passed to the linker.
> ---
> ffbuild/library.mak | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/ffbuild/library.mak b/ffbuild/library.mak
> index 793e9d41fa..781b018e00 100644
> --- a/ffbuild/library.mak
> +++ b/ffbuild/library.mak
> @@ -66,8 +66,10 @@ $(SUBDIR)$(SLIBNAME): $(SUBDIR)$(SLIBNAME_WITH_MAJOR)
>
> $(SUBDIR)$(SLIBNAME_WITH_MAJOR): $(OBJS) $(SHLIBOBJS) $(SLIBOBJS) $(SUBDIR)lib$(NAME).ver
> $(SLIB_CREATE_DEF_CMD)
> - $$(LD) $(SHFLAGS) $(LDFLAGS) $(LDSOFLAGS) $$(LD_O) $$(filter %.o,$$^) $(FFEXTRALIBS)
> + $(Q)echo $$(filter %.o,$$^) > $$@.objs
> + $$(LD) $(SHFLAGS) $(LDFLAGS) $(LDSOFLAGS) $$(LD_O) @$$@.objs $(FFEXTRALIBS)
> $(SLIB_EXTRA_CMD)
> + -$(RM) $$@.objs
Don't we need do the same for static libraries too?
On first glance, this looks quite reasonable... However, the limit that is
an issue is the length of a command line. The .objs file is written with
an "echo" command - doesn't that fundamentally also hit the same limit
(just a little bit later, as there are fewer command line flags in this
command)?
Or do we assume that make executes it with a shell, where the shell
handles "echo" as a shell builtin so that it doesn't actually spawn a
subprocess for this? Can you test it, if you could extend the list of
object files to the point where the .objs file is clearly over 32 KB, and
verify that it did include all the files you intended?
Secondly, less fundamental - even if we try to remove the .objs file here
at the same time it's quite possible for it to be left behind (e.g. if the
linking command fails) - so it would be good to make sure that it is
removed on "make clean" too.
Plus we probably should include it in .gitignore, if someone does in-tree
builds.
// Martin
More information about the ffmpeg-devel
mailing list