Argument list too long

[FrontierDK]

logs.zip

Hi all.

I am trying to build the non-free x86 shared build, but despite running the latest version, I get this error:
LD libavcodec/avcodec-61.dll
/bin/sh: line 1: /mingw32/bin/ccache: Argument list too long
make: *** [/build/ffmpeg-git/ffbuild/library.mak:119: libavcodec/avcodec-61.dll] Error 126

Log file(s) attached as per request.

When searching the web, some suggest putting the argument list into a file. More here: https://stackoverflow.com/questions/52391581/mingw32-bin-curl-argument-list-too-long

[L4cache]

Is this the time we finally reached the command line length limit (again?)?
I guess deduplicate linking flags is implemented some time in the past the limit was reached?

Put argument list into a file is not a common feature I suppose, but luckily GCC and Clang both support flags in a text file, the tricky part is that FFmpeg, like many other projects, is using build system, which may require a lot more effort to change.

[L4cache]

I can't reproduce this issue though...

[FrontierDK]

L4cache, try asking for a full shared x86 build, including libfdk, libjxl etc.

[1480c1]

Running the same configuration (mabs.ini, ffmpeg_options and mpv_options) resulted in the build passing for me. What is the folder path mabs is in? Perhaps your base path is too long?

[L4cache]

Oh yeah, and somehow the msys2 environment (the shell?) supports a single argument length up to nearly 12 MiB... and the total command line length limit is probably even longer.
So no need to worry that in any forseeable future as well...

/bin/bash -c "/bin/echo $(perl -e 'print"a"x12582885')"

[FrontierDK]

Running the same configuration (mabs.ini, ffmpeg_options and mpv_options) resulted in the build passing for me. What is the folder path mabs is in? Perhaps your base path is too long?

This worked, thank you. I had just used the full project name as a name for the root folder. Changing it to just "ffmpeg" enabled it to run all the way through :)

[LigH-de]

Happened to me too:
logs.zip
Base path is G;\MABS - so rather short.

Before that I tried to include librist, which still fails building

undefined reference to `BCryptGenRandom'

so I disabled it again in ffmpeg_options.txt; after that, building the dynamic ffmpeg started failing.

---

PS:

/bin/sh: line 1: /mingw64/bin/ccache: Argument list too long

I can't find in any log which command exactly it tried to execute. And the MinGW32 pass finished, probably because it loads a few less libraries (some only work in 64 bit code).

[LigH-de]

@rbouqueau confirms while testing to build GPAC and a dynamic ffmpeg, the bottleneck seems to be ccache.

Please re-open?

[rbouqueau]

I confirm I moved the build to a root folder and ccache still complained.

[LigH-de]

Request to re-open @1480c1

[L4cache]

It looks like something just randomly decided to stop working...
I also tried several fresh buils with issue author and LigH configurations (exact same configurations, directly copied from logs.zip) and can't reproduce the issue...

[LigH-de]

ccache=1 in INI: fails

ccache=2 in INI: fails too, reports /bin/sh: line 1: /mingw64/bin/ccache: Argument list too long despite having ccache disabled

logs.zip

Deleting all build directories and local result files.

[L4cache]

Disabling ccache in m-ab-s is actually "telling" ccache to not cache while still using ccache in compile commands.
You can delete ccache from these lines to make it completely disappear.

media-autobuild_suite/media-autobuild_suite.bat

Lines 1964 to 1969 in 7e35fbd

	if %CC%==clang (
	echo.export CC="ccache clang"
	echo.export CXX="ccache clang++"
	) else (
	echo.export CC="ccache gcc"
	echo.export CXX="ccache g++"

[LigH-de]

Tested that as well.

A GPL3 compatible license had just even not too many parameters, but a non-free build caused the same error even without ccache (in this case with g++). The command line has 29835 characters.

ab-suite.make.log

[L4cache]

I'm able to reproduce the error with a freshly installed Windows 10 VM this time, I suspect the culprit is the Windows Defender or the "path length limit". (WD is more likely)

Not actually...
My next suspicion is the "g++.bat" etc. wrapper created by suite.

I'm out of things to blame

[LigH-de]

Is it possible at all to feed library file name parameters to the linker via parameter file?

[L4cache]

I think for now you'll just have to limit the number of enabled libraries for shared ffmpeg, you can use a separate ffmpeg_options_shared.txt file.
Static build is not affected, for now.
Hmm, I wonder how last time I was not able to reproduce the error, I'm sure I didn't disable shared build or use separate options.

Is it possible at all to feed library file name parameters to the linker via parameter file?

It should be a viable solution but I guess that would require ffmpeg's build system to support it...

[BlohoJo]

I'm having the same problem.

Windows 10 Pro 2004 x64, running on VMware on a hypervisor.

Built successfully on November 12, 2024, but it had issues.

Trying again for the past couple days and not able to get past the "Argument list too long" error.

(Using pastebin due to Comment is too long (maximum is 65536 characters) error message.)
https://pastebin.com/pt3yxmsK

logs.zip

I've heard that this can be caused by the folder name being too long or too nested, but I'm running it in C:\mabs\media-autobuild_suite.bat. 😕

[BlohoJo]

~I'm able to reproduce the error with a freshly installed Windows 10 VM this time

Is the issue perhaps specific to doing it on a VM? Because I'm on a VM.

Is anyone else who's having this issue running on a VM / VPS?

[LigH-de]

In my case the suite is running directly on the host OS: Windows 10.

[ultrasound1372]

Same issue here, path is C:\tools\mabs, so not that long at all.
logs.zip

[BlohoJo]

Which .exe is actually throwing the error?

[LigH-de]

As far as I tested: ccache. But after I edited that out as @L4cache mentioned above, it was ld.

[BlohoJo]

If anyone has gotten it to work with a ffmpeg_options_shared.txt file, could you please share this file here? 😖

[L4cache]

Options in ffmpeg_options_shared.txt are applied on top of ffmpeg_options.txt, a bit weird, yes. You need to explicitly disable the less important to you libraries.
i.e. you need to (and maybe should only, in this case) put --disable-xxx in it.

[BlohoJo]

I've tried searching this but it's unclear... where does ffmpeg_options_shared.txt go? Under the build directory? Does ffmpeg_options.txt have to be present as well? Right now all I have is media-autobuild_suite.ini under the build directory.

[L4cache]

I've tried searching this but it's unclear... where does ffmpeg_options_shared.txt go? Under the build directory? Does ffmpeg_options.txt have to be present as well? Right now all I have is media-autobuild_suite.ini under the build directory.

You should have the customization option (or whatever else it is called) enabled and the default options is auto generated.

[LigH-de]

Batch configuration option:

Choose ffmpeg and mpv optional libraries?

When you selected option 1 here, build/media-autobuild_suite.ini will contain the entry ffmpegChoice=1 and the files build/ffmpeg_options.txt and build/mpv_options.txt will be generated with a default set of partially enabled libraries.

I used this option and enabled as many libraries as supported. This was certainly beyond a sane selection.

Alternatively, option 2 would use a quite useful selection as a "Light build"; option 3 would use a rather large selection similar to builds made by the Zeranoe autobuild site, and 4 would enable as many libraries as possible; all of these do not use text files to select single libraries but presets inside the media-autobuild_suite.bat.

[FrontierDK]

Just updated to the latest on both my x86 and x64 VMs (both run identical Windows 10 x64), one has x64 building of FFMPEG, one has x86. Last night, the x86 made it all the way through. The x64 did not (other error), so I updated to the latest version, and it failed with "list too long". Logs attached.
logs.zip

[BlohoJo]

If you don't need the shared (dll) versions, just build only the static libraries for FFmpeg and it should work.

:ffmpeg
if [0]==[%ffmpegB2INI%] (
    echo -------------------------------------------------------------------------------
    echo -------------------------------------------------------------------------------
    echo.
    echo. Build FFmpeg binaries and libraries:
    echo. 1 = Yes [static] [recommended]
    echo. 2 = No
    echo. 3 = Shared
    echo. 4 = Both static and shared [shared goes to an isolated directory]
    echo. 5 = Shared-only with some shared dependencies (libass, freetype and fribidi^)
    echo. 6 = Same as 4, but static compilation ignores shared dependencies
    echo.
    echo. Note: Option 5 differs from 3 in that libass, freetype and fribidi are
    echo. compiled shared so they take less space. Currently broken if libass or libass
    echo. dependees are enabled.
    echo. Option 6 produces static and shared ffmpeg and ffmpeg libs where the static
    echo. one includes only strictly static dependencies (opencl, opengl, cuda-nvcc,
    echo. libnpp, libopenh264 are hard disabled.^)
    echo.
    echo -------------------------------------------------------------------------------
    echo -------------------------------------------------------------------------------
    set /P buildffmpeg="Build FFmpeg: "
) else set buildffmpeg=%ffmpegB2INI%

So, in build\media-autobuild_suite.ini, set ffmpegB2=1.

Not sure if it's going to be possible to build the shared FFmpeg libraries again as the devs don't seem to know why it's failing with the "argument list too long" error. It's not actually too long, so it must be some bug or typo somewhere.

[FrontierDK]

I need the DLLs for web back-end usage, so .EXE is not an option.