strmbase is a static library which is used by amstream, qcap, quartz and others. This means functions defined in strmbase end up being included in amstream.dll.so and other places.
However modifying the strmbase code does not result in a relink of the dlls that depend on it. Note that this is true even if running make from the top-level directory. That makes it very painful to work with it.
Note that the same issue could happen with other static libraries like dxguid, uuid, etc, though those don't contain code and have little reason to change so that that's probably why the problem did not surface until now.
How should we fix this? Having amstream recusively run make in strmbase would break parallel builds (the top-level Makefile enforces ordering by having __builddeps__ depend on dlls/strmbase).
Would somthing like the patch below be acceptable? Should it be generalized to all the dependencies on uuid, dxguid, etc?
commit 0a6764918f743912a1f76ca004ec6d9f0d679b2a Author: Francois Gouget fgouget@free.fr Date: Fri Nov 9 19:45:21 2012 +0100
strmbase: Relink the dlls that depend on the strmbase static library when it changes.
diff --git a/dlls/amstream/Makefile.in b/dlls/amstream/Makefile.in index 35cfae1..5e96f1a 100644 --- a/dlls/amstream/Makefile.in +++ b/dlls/amstream/Makefile.in @@ -12,4 +12,8 @@ IDL_R_SRCS = amstream_classes.idl
RC_SRCS = version.rc
+$(MODULE).so: $(top_builddir)/dlls/strmbase/libstrmbase.a \ + $(top_builddir)/dlls/strmiids/libstrmiids.a \ + $(top_builddir)/dlls/uuid/libuuid.a + @MAKE_DLL_RULES@ diff --git a/dlls/qcap/Makefile.in b/dlls/qcap/Makefile.in index 3abc295..5f4078d 100644 --- a/dlls/qcap/Makefile.in +++ b/dlls/qcap/Makefile.in @@ -11,4 +11,8 @@ C_SRCS = \
RC_SRCS = version.rc
+$(MODULE).so: $(top_builddir)/dlls/strmbase/libstrmbase.a \ + $(top_builddir)/dlls/strmiids/libstrmiids.a \ + $(top_builddir)/dlls/uuid/libuuid.a + @MAKE_DLL_RULES@ diff --git a/dlls/quartz/Makefile.in b/dlls/quartz/Makefile.in index 24be02e..2cbcfe6 100644 --- a/dlls/quartz/Makefile.in +++ b/dlls/quartz/Makefile.in @@ -36,4 +36,9 @@ IDL_TLB_SRCS = control_tlb.idl
EXTRA_OBJS = dlldata.o
+$(MODULE).so: $(top_builddir)/dlls/dxguid/libdxguid.a \ + $(top_builddir)/dlls/strmbase/libstrmbase.a \ + $(top_builddir)/dlls/strmiids/libstrmiids.a \ + $(top_builddir)/dlls/uuid/libuuid.a + @MAKE_DLL_RULES@ diff --git a/dlls/winegstreamer/Makefile.in b/dlls/winegstreamer/Makefile.in index f6695be..cbf1986 100644 --- a/dlls/winegstreamer/Makefile.in +++ b/dlls/winegstreamer/Makefile.in @@ -12,4 +12,8 @@ C_SRCS = \ RC_SRCS = \ rsrc.rc
+$(MODULE).so: $(top_builddir)/dlls/strmbase/libstrmbase.a \ + $(top_builddir)/dlls/strmiids/libstrmiids.a \ + $(top_builddir)/dlls/uuid/libuuid.a + @MAKE_DLL_RULES@ diff --git a/dlls/wineqtdecoder/Makefile.in b/dlls/wineqtdecoder/Makefile.in index 52ee03b..762f837 100644 --- a/dlls/wineqtdecoder/Makefile.in +++ b/dlls/wineqtdecoder/Makefile.in @@ -12,4 +12,8 @@ C_SRCS = \ RC_SRCS = \ rsrc.rc
+$(MODULE).so: $(top_builddir)/dlls/strmbase/libstrmbase.a \ + $(top_builddir)/dlls/strmiids/libstrmiids.a \ + $(top_builddir)/dlls/uuid/libuuid.a + @MAKE_DLL_RULES@
Francois Gouget fgouget@free.fr writes:
strmbase is a static library which is used by amstream, qcap, quartz and others. This means functions defined in strmbase end up being included in amstream.dll.so and other places.
However modifying the strmbase code does not result in a relink of the dlls that depend on it. Note that this is true even if running make from the top-level directory. That makes it very painful to work with it.
Note that the same issue could happen with other static libraries like dxguid, uuid, etc, though those don't contain code and have little reason to change so that that's probably why the problem did not surface until now.
How should we fix this? Having amstream recusively run make in strmbase would break parallel builds (the top-level Makefile enforces ordering by having __builddeps__ depend on dlls/strmbase).
Would somthing like the patch below be acceptable? Should it be generalized to all the dependencies on uuid, dxguid, etc?
In theory yes, but that would have to be auto-generated. In practice only strmbase should matter.
On Mon, 12 Nov 2012, Alexandre Julliard wrote: [...]
Would somthing like the patch below be acceptable? Should it be generalized to all the dependencies on uuid, dxguid, etc?
In theory yes, but that would have to be auto-generated. In practice only strmbase should matter.
I'm not sure how to auto-generate it. Would something that looks like this be ok:
In Makefile.in:
STATICIMPORTS = strmiids strmbase uuid IMPORTS = $(STATICIMPORTS) ole32 advapi32
And in Makedll.rules.in:
$(MODULE).so: $(STATICIMPORTS:%=$(top_builddir)/dlls/%/lib%.a)
Or maybe:
$(MODULE).so: $(STATICIMPORTS:%=../dlls/%/lib%.a)
Or should explicit rules be added to the relevant makefiles by update_makefiles() in tools/make_makefiles.
Francois Gouget fgouget@free.fr writes:
On Mon, 12 Nov 2012, Alexandre Julliard wrote:
In theory yes, but that would have to be auto-generated. In practice only strmbase should matter.
I'm not sure how to auto-generate it. Would something that looks like this be ok:
In Makefile.in:
STATICIMPORTS = strmiids strmbase uuid IMPORTS = $(STATICIMPORTS) ole32 advapi32
And in Makedll.rules.in:
$(MODULE).so: $(STATICIMPORTS:%=$(top_builddir)/dlls/%/lib%.a)
Or maybe:
$(MODULE).so: $(STATICIMPORTS:%=../dlls/%/lib%.a)
In theory it should depend on all the import libs of course, but either way I don't think you can do that with standard makefile rules.
Or should explicit rules be added to the relevant makefiles by update_makefiles() in tools/make_makefiles.
It would have to be done by a script, but I don't think we want to have to put that sort of thing in the Makefile.in. I'd suggest to ignore the issue for now.
-
Alexandre Julliard -
Francois Gouget