winebuild and circular DLL dependencies

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

Alexandre Julliard wrote:
> Ove Kaaven <ovehk at> 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
are done by design by MS (Ove ran into Ole32/rpcrt4, there's also

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
  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
in the functions prototypes for LoadModule/GetProcAddress, which you
don't get with delay loading.

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

Eric Pouech (
"The future will be better tomorrow", Vice President Dan Quayle

More information about the wine-devel mailing list