Building with GHC 7.6.1 fails (Win8 x86_64), cabal 1.16, cabal-dev HEAD

[Morabbin]

Clean build from source yields:
...
[ 7 of 19] Compiling Paths_cabal_dev ( dist\build\autogen\Paths_cabal_dev.hs, d
ist\build\cabal-dev\cabal-dev-tmp\Paths_cabal_dev.o )
[ 8 of 19] Compiling Distribution.Dev.CabalInstall ( src\Distribution\Dev\CabalI
nstall.hs, dist\build\cabal-dev\cabal-dev-tmp\Distribution\Dev\CabalInstall.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... ghc.exe: internal error: R_X86_64_PC32: Hig
h bits are set in 7fa7fcb95a0 for WaitForSingleObject
(GHC version 7.6.1 for x86_64_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
cabal.exe: Error: some packages failed to install:
cabal-dev-0.9.1 failed during the building phase. The exception was:
ExitFailure 255

I'll investigate this with the GHC team, but thought I ought to report it here too.

[dagit]

On Tue, Jan 22, 2013 at 9:42 AM, Andy Adams-Moran
notifications@github.comwrote:

Clean build from source yields:
...
[ 7 of 19] Compiling Paths_cabal_dev (
dist\build\autogen\Paths_cabal_dev.hs, d
ist\build\cabal-dev\cabal-dev-tmp\Paths_cabal_dev.o )
[ 8 of 19] Compiling Distribution.Dev.CabalInstall (
src\Distribution\Dev\CabalI
nstall.hs,
dist\build\cabal-dev\cabal-dev-tmp\Distribution\Dev\CabalInstall.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... ghc.exe: internal error:
R_X86_64_PC32: Hig
h bits are set in 7fa7fcb95a0 for WaitForSingleObject
(GHC version 7.6.1 for x86_64_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug

Hi Andy!

This is actually a 64-bit GHC bug:
http://hackage.haskell.org/trac/ghc/ticket/7134
http://hackage.haskell.org/trac/ghc/ticket/7207
http://hackage.haskell.org/trac/ghc/ticket/7329

From what I can tell the plan is either to fix the homegrown linker or
depend on it less (I read somewhere that the builtin linker only supports
the small code model for x86_64 but windows uses the large code size
model). I couldn't get a sense for which path the ghc devs are actually
taking. In the meantime, I high recommend not using the 64bit ghc on
windows :(

Jason

[Morabbin]

Indeed; thanks!

On Jan 22, 2013, at 11:24 AM, Jason Dagit notifications@github.com wrote:

On Tue, Jan 22, 2013 at 9:42 AM, Andy Adams-Moran
notifications@github.comwrote:

Clean build from source yields:
...
[ 7 of 19] Compiling Paths_cabal_dev (
dist\build\autogen\Paths_cabal_dev.hs, d
ist\build\cabal-dev\cabal-dev-tmp\Paths_cabal_dev.o )
[ 8 of 19] Compiling Distribution.Dev.CabalInstall (
src\Distribution\Dev\CabalI
nstall.hs,
dist\build\cabal-dev\cabal-dev-tmp\Distribution\Dev\CabalInstall.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... ghc.exe: internal error:
R_X86_64_PC32: Hig
h bits are set in 7fa7fcb95a0 for WaitForSingleObject
(GHC version 7.6.1 for x86_64_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug

Hi Andy!

This is actually a 64-bit GHC bug:
http://hackage.haskell.org/trac/ghc/ticket/7134
http://hackage.haskell.org/trac/ghc/ticket/7207
http://hackage.haskell.org/trac/ghc/ticket/7329

From what I can tell the plan is either to fix the homegrown linker or
depend on it less (I read somewhere that the builtin linker only supports
the small code model for x86_64 but windows uses the large code size
model). I couldn't get a sense for which path the ghc devs are actually
taking. In the meantime, I high recommend not using the 64bit ghc on
windows :(

Jason
—
Reply to this email directly or view it on GitHub.