Re: wine/dlls Makefile.in rpcrt4/Makefile.in rpcrt ...

[Greg Turner]

On Thursday 10 October 2002 06:36 pm, Alexandre Julliard wrote:
> ChangeSet ID:	5742
> Patch: http://cvs.winehq.com/patch.py?id=5742
> --- wine/dlls/Makefile.in:1.155	Thu Oct 10 23:54:58 2002
> +++ wine/dlls/Makefile.in	Thu Oct 10 23:54:58 2002
> @@ -821,7 +821,7 @@
> quartz:   kernel32.dll$(DLLEXT)
> rasapi32: kernel32.dll$(DLLEXT)
> richedit: user32.dll$(DLLEXT) kernel32.dll$(DLLEXT)
> -rpcrt4:   kernel32.dll$(DLLEXT)
> +rpcrt4:   advapi32.dll$(DLLEXT) kernel32.dll$(DLLEXT)
> serialui: user32.dll$(DLLEXT) advapi32.dll$(DLLEXT) kernel32.dll$(DLLEXT)
> setupapi: user32.dll$(DLLEXT) advapi32.dll$(DLLEXT) kernel32.dll$(DLLEXT) ntdll.dll$(DLLEXT)
> shdocvw:  ole32.dll$(DLLEXT) kernel32.dll$(DLLEXT)
>
> Index: wine/dlls/rpcrt4/Makefile.in
> diff -u wine/dlls/rpcrt4/Makefile.in:1.15 wine/dlls/rpcrt4/Makefile.in:1.16
> --- wine/dlls/rpcrt4/Makefile.in:1.15	Thu Oct 10 23:54:58 2002
> +++ wine/dlls/rpcrt4/Makefile.in	Thu Oct 10 23:54:58 2002
> @@ -4,7 +4,7 @@
> SRCDIR    = @srcdir@
> VPATH     = @srcdir@
> MODULE    = rpcrt4.dll
> -IMPORTS   = kernel32
> +IMPORTS   = advapi32 kernel32
> EXTRALIBS = $(LIBUUID)
>
> LDDLLFLAGS = @LDDLLFLAGS@

Alexandre, thank you for continuing to make up for my ignorance of the inner workings
of the makefiles!  Amongst other things, I noticed that instead of IMPORTS += ntdll, you did
EXTRALIBS = ($LIBUUID).  So, this makes me wonder, how on earth does one know
what all these dependencies are?  It's all-too-easy to suck in some .h file and call methods
without knowing what dll dependencies you've really created... and unfortunately,
the darn thing seems all-too-happy to compile despite this.

Is there, aside from "just knowing," or tracing down API's one-by-one, a task which isn't always
obvious to me anyhow, a systematic way to check for broken dll dependencies?  I also presume
there are some rules about what is allowed to depend on what, which I also don't know...
I'd rather not create superfluous work for you because I don't know what I'm doing, so I
figure it's time to educate myself, especially if I plan to go beyond just feeding you patches
from Ove.

Thanks,

wine/dlls Makefile.in rpcrt4/Makefile.in rpcrt ...

[Alexandre Julliard]

Greg Turner  writes:
> Is there, aside from "just knowing," or tracing down API's
> one-by-one, a task which isn't always obvious to me anyhow, a
> systematic way to check for broken dll dependencies?

"make checklink" does this. It won't tell you which dependencies to
add though...
> I also presume there are some rules about what is allowed to depend
> on what, which I also don't know...

The basic rules are that you can't create circular dependencies, and
that in general you shouldn't import things that the equivalent dll
under Windows doesn't import.

wine/dlls Makefile.in rpcrt4/Makefile.in rpcrt ...

[Greg Turner]

On Thursday 10 October 2002 08:01 pm, Alexandre Julliard wrote:
> Greg Turner  writes:
> > Is there, aside from "just knowing," or tracing down API's
> > one-by-one, a task which isn't always obvious to me anyhow, a
> > systematic way to check for broken dll dependencies?
>
> "make checklink" does this. It won't tell you which dependencies to
> add though...

cool feature! btw, I get:

make[2]: Entering directory `/var/src/wine/dlls/msimg32'
gcc -o checklink -Wl,-rpath,../../dlls -Wl,-rpath,../../library -Wl,-rpath,../../unicode ../../library/checklink.c msimg32.dll.so && rm -f checklink
msimg32.dll.so: undefined reference to `SetLastError'

this solved it:

Index: dlls/msimg32/Makefile.in
===================================================================
RCS file: /home/wine/wine/dlls/msimg32/Makefile.in,v
retrieving revision 1.5
diff -u -r1.5 Makefile.in
--- dlls/msimg32/Makefile.in    17 May 2002 03:37:13 -0000      1.5
+++ dlls/msimg32/Makefile.in    11 Oct 2002 01:43:45 -0000
@@ -3,6 +3,7 @@
 SRCDIR    = @srcdir@
 VPATH     = @srcdir@
 MODULE    = msimg32.dll
+IMPORTS   = kernel32

LDDLLFLAGS = @LDDLLFLAGS@
 SYMBOLFILE = $(MODULE).tmp.o

This was already in dlls/Makefile.in.
> > I also presume there are some rules about what is allowed to depend
> > on what, which I also don't know...
>
> The basic rules are that you can't create circular dependencies, and

Makes sense
> that in general you shouldn't import things that the equivalent dll
> under Windows doesn't import.

Also makes sense.  Got it, thanks!