#7568: Can't dynamically load DLL-using libraries on Windows x86_64 -----------------------+---------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Windows | Architecture: x86_64 (amd64) Failure: GHCi crash | Blockedby: Blocking: | Related: -----------------------+---------------------------------------------------- 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. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7568 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler