Windows DLLs should be working.

[Ben Lippmeier]

Duncan Coutts wrote:
> On Sun, 2010-01-10 at 17:24 +1100, Ben Lippmeier wrote:
>   
>> Windows DLLs should be working now.
>>     
>
> Huzza. Great work Ben.
>
> So what was the solution in the end to the problem of the cross-module
> inlining and making intra vs inter DLL-calls?
>   

The solution was to refactor the foreign call code to track the 
packageIds of imported labels, and also put this information in the 
interface files.

For example, in the "integer-gmp" package, in the module 
"GHC.Integer.GMP.Internals" there is an import:

foreign import prim "integer_cmm_plusIntegerzh" plusInteger#
  :: Int# -> ByteArray# -> Int# -> ByteArray# -> (# Int#, ByteArray# #)

The code for plusInteger# is linked into the integer-gmp library, and 
appears in libHSinteger-gmp-version.dll. Now, when we're compiling 
GHC.Integer.GMP.Internals the renamer tags the plusInteger# label with 
the package that it's from (integer-gmp). If code that uses this label 
gets inlined into another package, we'll still know that the actual 
implementation of plusInteger# is in libHSinteger-gmp-version.dll.

For ELF(Linux) and MachO(OSX) it doesn't matter. When we're compiling in 
the "dyn" way on these platforms all foreign labels are taken to need 
dynamic linkage, and the linker just works it out. On Windows, we have 
to generate different code depending on whether a label needs dynamic 
linkage or not, so we have to track what package each label comes from.

Ben.