On 6 December 2012 09:27, Max Bolingbroke
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