Can't dynamically load DLL-using libraries on Windows x86_64
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 (closed).
Trac metadata
Trac field | Value |
---|---|
Version | 7.6.1 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |