[FFmpeg-devel] Re: [PATCH] configure: add -static suffix to internal static libs for test programs (PR #20837)

[Kacper Michajlow via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

On Wed, 5 Nov 2025 at 03:59, Zhao Zhili via ffmpeg-devel
<ffmpeg-devel@ffmpeg.org> wrote:
>
>
>
> > On Nov 5, 2025, at 02:15, Kacper Michajłow via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> >
> > PR #20837 opened by Kacper Michajłow (kasper93)
> > URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20837
> > Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20837.patch
> >
> > In MSVC builds, object files built for shared or static libraries are
> > technically not compatible with each other.
>
> Any reference? I don’t understand how does link static libraries work
> when object files not compatible. Is it related to av_export_avutil?

Yes, exactly. What happens in the MSVC world is that object files
carry information about dependencies and sybols and how data is
accessed from those dependencies.

I think the best answer is that Windows doesn't have "dynamic
linking", all it does is wrap static objects into thunks. So while
dllimport/dllexport attributes may look innocent, they are embedded in
object files and affect how linker links those objects to your
application. And simply if you say dllexport, you no longer can use
this object for static linking, because this symbol is expected to be
loaded from dll.

I'm glancing over details, but I hope it's enough for this discussion.

That's also why c6c80631868dbe96d9fe0b2a61181d970381191a was made,
because while accessing data without dllimport blows up, for function
pointers it's mostly an optimization of one indirection.

This topic is quite big to understand how linking on Windows works and
why sometimes dllimport is needed. I guess you can start here
https://learn.microsoft.com/en-us/cpp/build/exporting-from-a-dll
https://learn.microsoft.com/en-us/cpp/build/importing-data-using-declspec-dllimport
and follow related entries.

> > That's why building both
> > shared and static libraries simultaneously is not allowed in configure.
> >
> > However, for test programs, we still build internal static libraries
> > that allow the test programs to access internal symbols.
> >
> > In commit 8eca3fa619a7fb2190a3d4203e01a0d2661e7f91, I assumed that when
> > CONFIG_STATIC=0, we would never build a static library. We actually do
> > build one for internal purposes, ensuring that the objects are
> > "compatible", mostly by avoiding dllimport/dllexport attributes.
> >
> > Such libraries are never installed and are used only for test programs.
> > This change adds a -static suffix to these internal libraries to avoid
> > name conflicts. In the MSVC world, static libraries and import libraries
> > are generally the same thing and share the same naming conventions.
> >
> > Fixes: 8eca3fa619a7fb2190a3d4203e01a0d2661e7f91
> >
> >
> > From cd4a87fa07e22cdd1e7ea55743e9e4921c542d10 Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Kacper=20Michaj=C5=82ow?= <kasper93@gmail.com>
> > Date: Tue, 4 Nov 2025 19:06:06 +0100
> > Subject: [PATCH] configure: add -static suffix to internal static libs for
> > test programs
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > In MSVC builds, object files built for shared or static libraries are
> > technically not compatible with each other. That's why building both
> > shared and static libraries simultaneously is not allowed in configure.
> >
> > However, for test programs, we still build internal static libraries
> > that allow the test programs to access internal symbols.
> >
> > In commit 8eca3fa619a7fb2190a3d4203e01a0d2661e7f91, I assumed that when
> > CONFIG_STATIC=0, we would never build a static library. We actually do
> > build one for internal purposes, ensuring that the objects are
> > "compatible", mostly by avoiding dllimport/dllexport attributes.
> >
> > Such libraries are never installed and are used only for test programs.
> > This change adds a -static suffix to these internal libraries to avoid
> > name conflicts. In the MSVC world, static libraries and import libraries
> > are generally the same thing and share the same naming conventions.
> >
> > Fixes: 8eca3fa619a7fb2190a3d4203e01a0d2661e7f91
> > Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
> > ---
> > configure | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/configure b/configure
> > index 3b132d07c9..9c197a241c 100755
> > --- a/configure
> > +++ b/configure
> > @@ -6066,16 +6066,17 @@ case $target_os in
> >         ;;
> >     win32|win64)
> >         disable symver
> > +        LIBSUF=".lib"
> >         if enabled shared; then
> >             # Cannot build both shared and static libs with MSVC or icl.
> >             disable static
> > +            LIBSUF="-static.lib"
> >         fi
> >         ! enabled small && test_cmd $windres --version && enable gnu_windres
> >         enabled x86_32 && check_ldflags -LARGEADDRESSAWARE
> >         add_cppflags -DWIN32_LEAN_AND_MEAN
> >         shlibdir_default="$bindir_default"
> >         LIBPREF=""
> > -        LIBSUF=".lib"
> >         SLIBPREF=""
> >         SLIBSUF=".dll"
> >         SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)'
> > --
> > 2.49.1
> >
> > _______________________________________________
> > ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
> > To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org
>
> _______________________________________________
> ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
> To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org