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. _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool