Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
* [FFmpeg-devel] [PATCH] configure: add -static suffix to internal static libs for test programs (PR #20837)
@ 2025-11-04 18:15 Kacper Michajłow via ffmpeg-devel
  2025-11-05  2:58 ` [FFmpeg-devel] " Zhao Zhili via ffmpeg-devel
  0 siblings, 1 reply; 3+ messages in thread
From: Kacper Michajłow via ffmpeg-devel @ 2025-11-04 18:15 UTC (permalink / raw)
  To: ffmpeg-devel; +Cc: Kacper Michajłow

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. 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [FFmpeg-devel] Re: [PATCH] configure: add -static suffix to internal static libs for test programs (PR #20837)
  2025-11-04 18:15 [FFmpeg-devel] [PATCH] configure: add -static suffix to internal static libs for test programs (PR #20837) Kacper Michajłow via ffmpeg-devel
@ 2025-11-05  2:58 ` Zhao Zhili via ffmpeg-devel
  2025-11-05 11:27   ` Kacper Michajlow via ffmpeg-devel
  0 siblings, 1 reply; 3+ messages in thread
From: Zhao Zhili via ffmpeg-devel @ 2025-11-05  2:58 UTC (permalink / raw)
  To: FFmpeg development discussions and patches
  Cc: Kacper Michajłow, Zhao Zhili



> 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?

> 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [FFmpeg-devel] Re: [PATCH] configure: add -static suffix to internal static libs for test programs (PR #20837)
  2025-11-05  2:58 ` [FFmpeg-devel] " Zhao Zhili via ffmpeg-devel
@ 2025-11-05 11:27   ` Kacper Michajlow via ffmpeg-devel
  0 siblings, 0 replies; 3+ messages in thread
From: Kacper Michajlow via ffmpeg-devel @ 2025-11-05 11:27 UTC (permalink / raw)
  To: FFmpeg development discussions and patches; +Cc: Kacper Michajlow

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2025-11-05 11:28 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-11-04 18:15 [FFmpeg-devel] [PATCH] configure: add -static suffix to internal static libs for test programs (PR #20837) Kacper Michajłow via ffmpeg-devel
2025-11-05  2:58 ` [FFmpeg-devel] " Zhao Zhili via ffmpeg-devel
2025-11-05 11:27   ` Kacper Michajlow via ffmpeg-devel

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git