Failure under ghci/TH on 64bit Win7 #46

Open
ndmitchell opened this Issue Dec 30, 2012 · 6 comments

Projects

None yet

3 participants

@ndmitchell

A user has been been trying to install uniplate via Cygwin on Windows 7x64 running ghc 7.6.1, with Cabal 1.16.0.2. The compilation of Uniplate is failing related to " __imp_CryptAcquireContextA", with the error:

ghc.exe: unable to load package `hashable-1.2.0.2'
ghc.exe: C:\Program Files\Haskell\hashable-1.2.0.2\ghc-7.6.1\HShashable-1.2.0.2.o: unknown symbol `__imp_CryptAcquireContextA'

I advised the user downgrade to hashable-1.1 which worked.

@bos
Collaborator

This affects code loaded at runtime by ghci (and thus TH), but not normal applications.

I think the issue might be that we're not linking against the import library at compile time - I'm trying to verify this.

@bos
Collaborator

Okay, here's what I think I see so far.

MinGW ships with its own version of wincrypt.h. Under Win64, this prefixes names with __imp_, presumably to later be resolved by the "import library" libadvapi32.a, which also ships with MinGW.

However, at runtime, ghci loads advapi32.dll, which quite reasonably does not have those forwarding thunks with __imp_ prefixes.

We're being screwed by the fact that MinGW expects our object file to be linked against its library so that the forwarding thunks can be linked in, but the ghc runtime linker isn't in on the game, doesn't load it, and we die.

@bos bos added a commit that referenced this issue Jan 11, 2013
@bos bos When building with -ffixed-salt, don't pull in any PRNG code
This is necessary to get us working with GHCi 7.6.1 on Windows x64.

See gh-46 and http://hackage.haskell.org/trac/ghc/ticket/7568 for the
unhappy details.
7d6fe7d
@bos
Collaborator

This is hopeless. There are simply too many bugs in GHC on Win64. See trac 7568 for the unhappy details. I've spent most of the day trying to work around this, and have given up.

As a workaround, your user can compile hashable with -ffixed-salt. I just pushed 7d6fe7d, which I have tested and found to work on x64.

@bos
Collaborator

Better trac tickets: 7097 and 7134.

@khorser

@bos Have you tried to extract C code into a dynamic library like wxHaskell does? You will need to supply it in GHCi command line anyway though.

@bos
Collaborator
bos commented Feb 2, 2013

@khorser Loading dynamic libraries is the problem. Adding another one helps nothing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment