Missing dependencies on static libraries
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(a)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(a)free.fr> http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".
Francois Gouget <fgouget(a)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. -- Alexandre Julliard julliard(a)winehq.org
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(a)free.fr> http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.
Francois Gouget <fgouget(a)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 julliard(a)winehq.org
participants (2)
-
Alexandre Julliard -
Francois Gouget