Opened 3 years ago

Closed 3 years ago

#7568 closed bug (duplicate)

Can't dynamically load DLL-using libraries on Windows x86_64

Reported by: bos Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.6.1
Keywords: Cc:
Operating System: Windows Architecture: x86_64 (amd64)
Type of failure: GHCi crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

I've spent the past day trying to understand and fix this downstream bug:

https://github.com/tibbe/hashable/issues/46

There are two unrelated bugs at play. Please let me know if you'd like me to file them separately.

Test case

Both bugs have a very simple reproduction script.

import Data.Hashable
import Data.Text

main = print . hash . pack $ "/"

First bug

The first problem arises when we compile some C code for inclusion into a Haskell library, and that C code includes references to functions in a standard Windows DLL.

In this case, names from the DLL are prefixed with imp_, in the expectation that the mingw "import library" will be linked against. However, the ghc runtime linker knows nothing about these import libraries (they're .a files buried in the mingw tree) and just tries to load the DLL, whereupon symbol resolution fails.

To reproduce:

git clone git://github.com/tibbe/hashable.git
git checkout master
cabal install
runghc ....../Crash.hs

Second bug

I came upon the second problem while trying to work around the first.

cd hashable
git checkout origin/win64
cabal install
runghc ...../Crash.hs

In this case, I get a crash due to the wrong relocation size being used:

Crash.hs: internal error: R_X86_64_PC32: High bits are set in 7fefc4ece1d for CryptReleaseContext
    (GHC version 7.6.1 for x86_64_unknown_mingw32)

This latter case looks similar to #7134.

Change History (1)

comment:1 Changed 3 years ago by simonmar

  • difficulty set to Unknown
  • Resolution set to duplicate
  • Status changed from new to closed

The first bug is #7097, there's a long discussion there (but no solution). What I don't understand is that we have lots of C code in libraries that calls functions in Windows DLLs, and it all works fine in GHCi, so what is special here?

The second bug does look like #7134, as you say. So I'm closing this as a duplicate, and I'll add a ref from #7097 and #7134.

Note: See TracTickets for help on using tickets.