winebuild and circular DLL dependencies

eric pouech eric.pouech at wanadoo.fr
Fri Oct 12 12:47:45 CDT 2001


Alexandre Julliard wrote:
> 
> Ove Kaaven <ovehk at ping.uio.no> writes:
> 
> > Well, can this be done with delayed imports yet? I have a situation here
> > where ole32 imports stuff from rpcrt4 (windows uses delayed imports for
> > that), and rpcrt4 imports stuff from ole32 (again, windows uses delayed
> > imports). It would be nice if I could use the winebuild delayed import
> > mechanism to achieve this, instead of doing it manually with callout
> > tables and stuff... but I suppose winebuild has to be changed to read
> > the .spec files instead of using nm on compiled libraries... anyone
> > working on it?
> 
> No, and I don't think it's a desirable feature, it's too error-prone.
> Besides, circular dependencies are really something to avoid, so it
> must not be too easy to do... (what does rpcrt4 need from ole32 BTW?)
<< à l'impossible, nul n'est tenu >>
well, I think we need to differentiate two things:
- circular deps in normal imports
- circular refs of DLLs for delayed imports

doing the later with either pairs or delay loading
doesn't change much. We still have the circular refs of DLLs. Some of
them
are done by design by MS (Ove ran into Ole32/rpcrt4, there's also
comctl32/msvideo).

Could you explicit a bit more what you the error-prone side of this ?
I only see drawback with current implementation of delay imports:
- calling a delayed function in libmain could cause some issues to the
dynamic
  loader... this can be easily fixed
- there's so error reporting mechanism in delay imports. this is
supported by
  MS, the correct functions are not hooked in.

Apart from that, I don't see nothing execpt, that you can introduce
errors
in the functions prototypes for LoadModule/GetProcAddress, which you
usually
don't get with delay loading.

from a tree build point of view, using .spec vs nm output for symbol
lookup
wouldn't change anything

A+
-- 
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle




More information about the wine-devel mailing list