Hi *, I’ve been working the past 4 or so months on reviving dynamic linking support for Windows in a way that has the most chance of working.
My first patch in the series is up on Phabricator and with this patch dynamic linking work again, but only for the threaded RTS. The reason for this is because the core libraries that get distributed with GHC get compiled with -threaded and shared libraries on Windows can’t have dangling symbols. In any case, I’m at the point now where I need to be able to delay the selection of the runtime library till the final link. E.g. when the exe or dll is made. The problem however is that when linked normally, dependencies are satisfied by the Windows loader, before the program is run. One way I could do this is with Window’s equivalent to SONAME. Unfortunately this only works with SxS Assemblies, and I’ll need Admin rights to be able to register the shared libraries. This is a problem for running tests in the testsuite using the inplace GHC. Typically on Windows the way you would do this is by delay loading the dll. This allows me to write some code on startup and manually load the runtime dll. The Windows loader would then just use the loaded dll. Unfortunately delay loading does not support const extern data. Such as const extern RtsConfig defaultRtsConfig; The RTS/GHC is full of such usage so it won’t be easy to change. Though I’d only have to change those exposed by Rts.h. So I have two options: 1) Replace all const externs with a function call. This would work, but isn’t ideal because it would break if someone in the future adds a new data entry instead of a function. And we have an extra function call everywhere. 2) I could do some hacks on the Windows side, e.g. compile the program to a shared library, embed the shared library inside the exe and on startup after loading the propert rts, load the DLL from (mmapped) memory and run the code. I don’t like either approach and am hoping someone here has a better solution for me. Thanks, Tamar
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
