Can anyone think of a way to get circular dependencies between windows DLLs?

[Dave Korn]

    Hi all,

  I have an interesting problem to try and solve: I need to create
circularly-dependent shared libs using libtool on Windows(*).

  This is trivial on the ELF targets that libtool supports because you just
leave undefined references in both the libraries, link them against each
other, and the loader fixes it all up at runtime.

  On Windows we have the well-known restriction that you can't have undefined
symbols in libraries at link time.  Any imports from another library have to
be resolved by linking against the import stub from the relevant import
library.  These import libraries are generated as a side-effect of linking the
shared library DLL itself; so what libtool can't do on Windows is build two
libraries that both refer to symbols from the other, because whichever one it
tries to link first, the import library for the other hasn't been created yet.

  Fortunately that's not a problem in this particular case, because in one
direction there aren't actually any undefined references that would cause
linking to fail; what I'm trying to do is create an entirely artificial forced
dependency(*) in that direction only, and if it wasn't for that this would
just be a straightforward case of one library dependent on another.

  As a proof of concept, I created a dummy .def file containing the name of a
single symbol from the DLL I wanted to create a dependency on, used dlltool to
build an import library from that, and cut-and-pasted the libtool-generated
final link line for the DLL that I wanted to have the dependency, adding the
import library I had just built (using --whole-archive).  This worked
perfectly; I got a DLL which imported a symbol from the other DLL, and any
application which linked against either DLL caused both to be loaded at
runtime, which was my goal.

  The question, then, is this: can I get libtool to do this for me?

  More specifically, can I get libtool to do this for me, without having to
modify it (or do anything else unsuitable for GCC stage 3)?

  I don't think I can get libtool to build the dummy import library for me as
a libtool-controlled convenience library, so I think I'm left with just
building the .a file as an ordinary target in my makefile and trying to
persuade libtool to link it in, but I couldn't figure out how to do that.
Libtool either complained about not knowing how to link against a static
archive, or listed my bogus import library in the dependent_libs; I'm pretty
sure I don't want it to do that, since this is a temporary build-time artifact
only and will not be installed.  I /think/ I tried every combination of using
-limportlib vs. libimportlib.dll.a and of adding it or not to _LDADD vs.
_DEPENDENCIES vs. _LDFLAGS, but I might have overlooked something, I'm not
fully fluent in libtool-ese.

  An additional (minor) problem is whether I could get it to link this .a file
only into the shared library and not the static archive (although I think it
wouldn't matter if I can't avoid that, but I'd rather be tidy).


  Is this at all possible then?  Just shove an arbitrary .a file into the
final link of a libtool shared library DLL without libtool wanting to know
anything about it?

    cheers,
      DaveK
-- 
(*) - In order to simplify this post, I'd like to skip over the entire
justification of /why/ I want to do this, and whether it wouldn't be better to
 adopt a different solution.  Anyone interested in the gory details can read
GCC PR42811, but for the purposes of discussion, let us just assume that this
is indeed the correct and even best solution to the problem at hand.