winebuild and circular DLL dependencies
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
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
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 (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
More information about the wine-devel