Solve recursive DLL dependency between RTS and ghc-internal
The RTS and ghc-internal shared libraries depend on each other: each has references to things defined in the other. In particular, there is a single symbol (init_ghc_hs_iface) used in the RTS that is defined in ghc-internal.
On ELF platforms this is unproblematic because ELF shared libs can contain undefined references. On Windows it is a problem because PE DLLs cannot contain undefined references: every reference must be resolved to some DLL dependency (or internally). PE DLLs can depend on each other recursively however, it just requires using import libraries. An import library is a static library (.a) that is included when linking a .dll that defines all the symbols exported by the other .dll (which itself is not used during the linking process). An import library can be created from a .def text file that lists the symbol exports. This allows the import lib to be created before the dll itself, and this allows us to resolve the cycle.
The only symbol that the rts imports from the ghc-internal package now is init_ghc_hs_iface. So the rts only needs an import lib that defines that one symbol (rather than the very large number of symbols that ghc-internal actually exports).
So what we do is:
- generate
libHSghc-internal.deffrom a.def.infile - generate
libHSghc-internal.dll.afromlibHSghc-internal.defusing thedlltool(from the system toolchain) - include
libHSghc-internal.dll.awhen linkinglibHSrts.dll
And then linking libHSghc-internal.dll can be normal against all its dependencies, using libHSrts.dll, which by then exists.
So it is just the one "backwards" link in the dependency graph that we have to treat specially, and everything else can follow the normal non-cyclic DAG style build graph.
So this MR:
- Adds support for
dlltoolto the GHC toolchain abstraction - Adds support for
dlltoolto the hadrian build system's "Builder" abstraction - Adds a rule to build the import lib
libHSghc-internal.dll.aand use it when linking the RTS dll.
This is a part of the work needed for full support for dynamic linking on windows, issue #27162.