On Tue, 9 Oct 2012, Måns Rullgård wrote:
Martin Storsjö <mar...@martin.st> writes:
DEP_LIBS is part of $^, since DEP_LIBS is a dependency of the
test tools. The libs, that originate in the FFLIBS variable,
are added into FFEXTRALIBS already (normally in the form -lavutil),
but via DEP_LIBS in the literal form as libavutil/libavutil.so.
Previously, when building test tools, the make file invoked
the linker with the parameters "libavutil/libavutil.so -lavutil".
On linux this worked just fine.
On mingw, the linker actually can handle being given both the literal
DLL name or using the -lavutil parameter (and handle multiple copies
of them), but when using both forms at the same time for the same
library, the mingw linker trips up.
On msvc, the linker can't handle being passed the literal DLL name
at all.
This fixes running fate on mingw with DLLs enabled.
---
library.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/library.mak b/library.mak
index a68ab14..ca368a0 100644
--- a/library.mak
+++ b/library.mak
@@ -36,7 +36,7 @@ install-libs-$(CONFIG_SHARED): install-lib$(NAME)-shared
define RULES
$(EXAMPLES) $(TESTPROGS) $(TOOLS): %$(EXESUF): %.o
- $$(LD) $(LDFLAGS) $$(LD_O) $$^ $(FFEXTRALIBS) $$(ELIBS)
+ $$(LD) $(LDFLAGS) $$(LD_O) $$(filter-out $(DEP_LIBS), $$^)
$(FFEXTRALIBS) $$(ELIBS)
$$(filter %.o,$$^) seems simpler and possibly more robust. We already
use this for creating the actual shared libs.
True, that sounds simpler. I think there's an issue with that though, for
examples/tools, $^ includes $(THIS_LIB).
That particular case also is an issue for MSVC, since $(THIS_LIB) is the
literal DLL file name, while the linker needs to get the equivalent of
-lfoo - that is, replacing $(THIS_LIB) with $(NAME:%=$(LD_LIB)) in the
linker args.
// Martin
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
