lonetiger@gmail.com writes:
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.
Thanks for all of your work on this, Tamar!
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.
Let me make sure we are on the same page here: By "dangling symbols" do you just mean symbols that the linker did not find a definition for at link time (e.g. as is the case with libHSrts symbols when we link libHSbase)?
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.
Hmm, why? I thought recent Windows releases had a notion of "user local" installation, no? From what little I have heard it sounds like SxS assemblies is the right solution here.
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;
Silly Windows.
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.
Right, I'm really not a fan of this option. Crippling the RTS's use of C on account of arbitrary limitations of the Windows dynamic linker doesn't seem very appealing.
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.
This sounds like it would get the job done, although it certainly adds complexity. Do you have any intuition for how much work it would be to implement this? Cheers, - Ben