Windows failure: libCffi.a not found

[snowleopard]

After #566, Windows build fails with a new copyFile error caused by the fact that on Windows the FFI library is called libCffi-6 instead of libCffi.

I've made the following change on my machine and this seems to work:

    if os(windows)
      extra-bundled-libraries: Cffi-6
    else
      extra-bundled-libraries: Cffi

@angerman Does this look right to you? Shall I send a patch to GHC?

[snowleopard]

Encouraged by @alpmestan's thumbs up, I sent a patch: https://phabricator.haskell.org/D4590 :)

[alpmestan]

In spirit this is definitely the right thing to do, and we should expect more and more changes to rts.cabal.in because with Hadrian using Cabal directly, we need to have the cabal file reflect exactly what's produced, unlike with the Make build system which just does a bit of magic internally to produce all the libraries with all the suitable flavours. We just need to make sure with @Mistuke that the actual change is good or to replace it with something even better in the long term (the point about version change is a good one IMO, I just don't know what alternative we have).

[snowleopard]

@alpmestan Yes, I'm sure this can be improved further. This seems to be a good first step, as it allows us to have a working Windows build without adding any special magic to Hadrian.

[snowleopard]

The patch has been accepted and @Mistuke added detailed comments, copied below for future reference:

@snowleopard it's not. But I don't think it's Hadrian's job to fix this. So I'll accept this because make did it and it fixes Hadrian.

But this is wrong. It's using a very dangerous feature that only LD supports of bypassing the PLT and GOT entries and linking directly to the addresses found in the IAT of the dll.

This is dangerous because the code in the dll is written with the small memory model, it assumes that it's PLTs are always within the 32 gb range. So the relocations it generates are 32 bit relocations.

However the preferred image base of a dll can force the dll to be outside the range. Without the extra indirection inside the import libraries you will end up linking against an address that is too large.

Ld will truncate the address and leave you with very hard to diagnose segfaults.

This is just a common misunderstanding. Windows has PLT and GOTs. The difference is that unlike the System V variants they are external instead of inside the so itself.

At some point, this really should be fixed @bgamari

[snowleopard]

I think this issue can now be closed.