[FFmpeg-devel] [PATCH] tools: Don't include the direct library names when linking

Martin Storsjö martin at martin.st
Mon Oct 2 14:24:30 EEST 2023


On Thu, 28 Sep 2023, Martin Storsjö wrote:

> When linking the main tools, the object files to link are set up
> via the variable OBJS-<name>, but for the tools, we've only
> used the target's list of dependencies.
>
> In most cases, this has been fine, but it has caused specifying
> the libraries to link in a duplicate fashion; the linking command
> has looked like this:
>
>    $CC -Llibavutil ... tools/tool.o libavutil/libavutil.a -lavutil
>
> Normally, the libraries to link are handled with "-Llibavutil -lavutil";
> when linking the main fftools, this is how they are linked.
>
> In the case of the binaries under the "tools" directory (within the
> make variable TOOLS), we've passed the full set of dependencies
> to the linker, via $^, which does contain the names of the
> dependency libraries as well.
>
> When libraries are built as regular static libraries, or shared
> unix libraries, this has all worked fine. When libraries are
> built as DLLs for Windows, though, the norm is not to pass the
> actual DLL to the linker, but an import library.
>
> Mingw tools generally can handle linking directly against a DLL
> as well, but MSVC tools don't support that, and error out with
> a very cryptic error message:
>
>    libavdevice\avdevice.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2D8
>
> By omitting these parts of the dependencies, linking of these tool
> executables succeed in MSVC builds with shared libraries enabled.
> ---
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)

Acked by Hendrik on irc (last week, referenced by Andreas), will push 
later today.

// Martin


More information about the ffmpeg-devel mailing list