creswick
Building with GHC 7.6.1 fails (Win8 x86_64), cabal 1.16, cabal-dev HEAD
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.
On Tue, Jan 22, 2013 at 9:42 AM, Andy Adams-Moran [email protected]:
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
Indeed; thanks!
On Jan 22, 2013, at 11:24 AM, Jason Dagit [email protected] wrote:
On Tue, Jan 22, 2013 at 9:42 AM, Andy Adams-Moran [email protected]:
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.