Dynamic libraries by default and GHC 7.8

[Max Bolingbroke]

On 6 December 2012 09:27, Max Bolingbroke <batterseapower at hotmail.com> wrote:
> I'm not sure how to convince GNU ld to link us such a DLL, though. It
> might be possible to hack it in by linking against
> "verylongdummydllname.dll" and then having GHC search for that string
> in DLL/EXE returned by LD and replace it by the null-terminated
> absolute path.

While I was in the shower I figured out how to make this work:

 1. We need to create an *import library* for every Haskell DLL. This
import library will export all the functions exported by the normal
DLL, but we will ensure that it has an absolute path name in the
.idata section
 2. To create the import library, there are two methods:
  a) If we know all the object files that went into linking the DLL
(we don't care about other linker flags like the DLLs that the current
DLL depends on), we can just use "dlltool --output-lib foo.lib <object
files>" to generate the library.
  b) If we don't know the object files, we will instead have to create
a .def file using mingw's pexports utility/nm/dumpbin, and then run
"dlltool --output-lib foo.lib -d foo.def"
 3. In ether case, we should create the object file with --dllname
verylongdummymodulename.dll
 4. After dlltool returns, we simply go into the import library and
replace the dummy module name with the absolute path
 5. When linking against Haskell DLLs later on, simply link against
the import library rather than the DLL itself

I've tested this by hand and it seems like it works: the absolute
paths you hack into the import library are not messed with by the
later link step. The resulting executables run flawlessly. Job done.

Seem plausible?

Max