Overlong command line arguments on Windows WAS Could not execute: .../gcc.exe

[rubenmoor]

Maybe related to #466, however I don't run into the CreateProcess problem described there, anymore.

During stack build on Win7 I get the following error, no executable being created. This only happened after adding dependencies to the libraries

-- build-depends in cabal file
base64-bytestring
RSA
stm

I'll revisit once I identified the culprit.

    Linking .stack-work\dist\i386-windows\Cabal-1.22.4.0\build\core-server\core-server.exe ...
    ghc.exe: could not execute: C:\Users\metrix\AppData\Local\Programs\stack\i386-windows\ghc-7.10.2\lib/../mingw/bin/gcc.exe

--  While building package core-0.1.0.0 using:
      C:\\Users\\metrix\\AppData\\Local\\Programs\\stack\\i386-windows\\ghc-7.10.2\\bin\\runhaskell.exe -package=Cabal-1.22.4.0 -clear-package-db -global-package-db -package-db=C:\Users\metrix\AppData\Roaming\stack\snapshots\i386-windows\nightly-2015-08-11\7.10.2\pkgdb\ C:\Users\metrix\AppData\Local\Temp\stack4776\Setup.hs --builddir=.stack-work\dist\i386-windows\Cabal-1.22.4.0\ build
    Process exited with code: ExitFailure 1

[joozek78]

Happened to me also, after upgrading stack. Now I'm trying to revert to 0.1.1.0 and can't find x64 version, strange...

[themoritz]

That's definitely related to the command length limitations discussed in #466.

I could get all the dependencies mentioned by @rubenmoor compiled and linked in a smaller project. However, adding them to our project which already has quite many dependencies results in the exact same error.

[snoyberg]

I've changed the title of this issue to reflect the core issue. As I can see it, there are four different places where this problem could be resolved:

1. In Windows itself (highly unlikely to happen)
2. In GHC, by figuring out a different way to pass arguments to the linker that doesn't trip the limit
3. In Cabal (the library), by not putting each library in its own directory, or other ways of artificially reducing the size of the arguments
4. In stack, by figuring out some way to make the paths shorter

I'd prefer (2) to be the approach taken, as it's the right one and most resilient, but I don't know how feasible it is.

[snoyberg]

GHC trac ticket opened: https://ghc.haskell.org/trac/ghc/ticket/10777#ticket

[themoritz]

Agree that (1) or (2) are preferable since reducing path or argument length is only a solution until you get a project with even more dependencies. At the beginning, moving our project to C:\ helped, but now we're stuck again.

For the time being though, I'd be happy with any hack...

[snoyberg]

@themoritz One thing you could try is applying this patch to the Cabal library:

https://ghc.haskell.org/trac/ghc/ticket/10777#comment:2

Then you can install that library globally and stack will use it.

[joozek78]

How should I install it? I tried cabal install, stack install and manually adding to $(stack path --snapshot-pkg-db)

[snoyberg]

The following should work:

stack exec --no-ghc-package-path -- cabal install --global

We have code in Stack.Setup for doing this, but it's not generalized (at least yet) for local directories.

[themoritz]

Is there another way to install the patched cabal version so that stack will use it? The above command does not work because of #813.

[snoyberg]

How about:

1. Run stack exec which ghc
2. Add the resulting directory to your PATH
3. Run cabal install --global

[themoritz]

Okay, I just tested the patched cabal version and still get the same error:

ghc.exe: could not execute: C:\Users\Moritz\AppData\Local\Programs\stack\i386-windows\ghc-7.10.2\lib/../mingw/bin/gcc.exe

For anyone who wants to try it, here is the patched cabal: https://github.com/themoritz/cabal/tree/rsp-files

As a side note: With stack 0.1.3.1 x86_64, I ran into the gcc.exe: error: CreateProcess: No such file or directory error, so I switched to the i386 version (I have a 64-bit Win 7).

[snoyberg]

I'm not terribly surprised by that. I do think this will need to be fixed in GHC itself, not Cabal.

[joozek78]

Any ideas how could I work around that? Dropping windows is not an option for me and I already reduced my dependencies to minimum and even shortened paths.
It looks like I'll have to switch back to cabal :(

[snoyberg]

I'm surprised that cabal is working in that case... did you try the hack of moving your project directory to C:? And when you build with cabal, are you using sandboxes?

You may have to temporarily go back to cabal in this case, at least until GHC is patched for this.

[borsboom]

A thought: even if the project is moved to C:, the stack root (the equivalent to ~/.stack on Un*x) would still be somewhere your home directory. Might it help to set the STACK_ROOT environment variable to point to a short directory (e.g. C:\STK)?

[snoyberg]

FYI, I just pushed a commit to my GHC fork on the 7.10 branch to hopefully fix this:

snoyberg/ghc@7fc75d9

I'm trying to rebuild GHC on Windows now. If that works, I can upload a bindist for others to test/use.

[snoyberg]

I've sent a Phabricator diff for this:

https://phabricator.haskell.org/D1158

Unfortunately, I have not been successful at building on Windows, so if someone else wants to take a crack at it, I'd appreciate it.

[joozek78]

I tried moving project root and it didn't help. I'm building without sandbox, using stack's package dbs:

PATH=/path/to/stack/ghc:$PATH cabal configure --package-db=clear --package-db=global --package-db=$(stack path --snapshot-pkg-db) --package-db=$(stack path --local-pkg-db)
PATH=/path/to/stack/ghc:$PATH cabal build

I'm using patched version of latest cabal.
What's interesting is that GHC 7.8.4 succeeds, but 7.10 fails

[snoyberg]

It's not surprising that 7.10 fails. 7.10 added a bunch of new stuff for Backpack, which caused file paths to become significantly longer. This is not the first Windows bug due to it.

[snoyberg]

Alright, current status:

• I've put together a branch of GHC 7.10 that has four different commits for Windows. I'm trying to get them merged upstream for both master and the 7.10.3 release.
• In my testing, this change seems to fix the problem described here (and I'd be very surprised if it didn't, given how the change works).
• I have not been successful at generating a bindist of these.

My suggested steps forward:

• Someone who's affected by this bug: please try building my branch and using it with stack. In order to do so, you'll want to modify your PATH to include both the bin and mingw/bin directories generated by the installation
• We'll make some modification to stack to make it easy to install arbitrary bindists. @3noch and @borsboom have been doing something similar already with variants, I'll touch base with them to see if we can piggy-back this somehow

[joozek78]

I'll check it after the weekend.

On Fri, 21 Aug 2015 at 15:00 Michael Snoyman notifications@github.com
wrote:

Alright, current status:

• I've put together a branch of GHC 7.10
  https://github.com/snoyberg/ghc/tree/ghc-7.10 that has four
  different commits for Windows. I'm trying to get them merged upstream for
  both master and the 7.10.3 release.
• In my testing, this change seems to fix the problem described here
  (and I'd be very surprised if it didn't, given how the change works).
• I have not been successful at generating a bindist of these.

My suggested steps forward:

• Someone who's affected by this bug: please try building my branch
  and using it with stack. In order to do so, you'll want to modify your PATH
  to include both the bin and mingw/bin directories generated by the
  installation
• We'll make some modification to stack to make it easy to install
  arbitrary bindists. @3noch https://github.com/3noch and @borsboom
  https://github.com/borsboom have been doing something similar
  already with variants, I'll touch base with them to see if we can
  piggy-back this somehow

—
Reply to this email directly or view it on GitHub
#795 (comment)
.

[joozek78]

:(

2015-08-25 18:53:09.8188472: [info] Linking .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\gs\gs.exe ... @(stack-0.1.3.1:Stack.Build.Execute src/Stack\Build\Execute.hs:905:35)
2015-08-25 18:53:09.9629436: [warn] gcc.exe: error: CreateProcess: No such file or directory @(stack-0.1.3.1:Stack.Build.Execute src/Stack\Build\Execute.hs:905:35)
2015-08-25 18:53:10.0209821: [warn] ghc: warning: _tzset from msvcrt is linked instead of __imp__tzset @(stack-0.1.3.1:Stack.Build.Execute src/Stack\Build\Execute.hs:905:35)

--  While building package greenticket-0.1.0.0 using:
      C:\\Users\\marcin\\local\\bin\\runhaskell.exe -package=Cabal-1.22.4.0 -clear-package-db -global-package-db -package-db=C:\Users\marcin\AppData\Roaming\stack\snapshots\x86_64-windows\lts-3.1\7.10.2.20150823\pkgdb\ C:\msys64\tmp\stack9560\Setup.hs --builddir=.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\ build exe:gs --ghc-options -hpcdir .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\hpc\.hpc\ -ddump-hi -ddump-to-file
    Process exited with code: ExitFailure 1

I hope I'm doing something wrong and someone will confirm this patch works. Any ideas?

[snoyberg]

Can you paste the output of ghc --info?

On Tue, Aug 25, 2015, 9:57 PM Marcin Goliński notifications@github.com
wrote:

:(

2015-08-25 18:53:09.8188472: [info] Linking .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\gs\gs.exe ... @(stack-0.1.3.1:Stack.Build.Execute src/Stack\Build\Execute.hs:905:35)
2015-08-25 18:53:09.9629436: [warn] gcc.exe: error: CreateProcess: No such file or directory @(stack-0.1.3.1:Stack.Build.Execute src/Stack\Build\Execute.hs:905:35)
2015-08-25 18:53:10.0209821: [warn] ghc: warning: _tzset from msvcrt is linked instead of __imp__tzset @(stack-0.1.3.1:Stack.Build.Execute src/Stack\Build\Execute.hs:905:35)

-- While building package greenticket-0.1.0.0 using:
C:\Users\marcin\local\bin\runhaskell.exe -package=Cabal-1.22.4.0 -clear-package-db -global-package-db -package-db=C:\Users\marcin\AppData\Roaming\stack\snapshots\x86_64-windows\lts-3.1\7.10.2.20150823\pkgdb\ C:\msys64\tmp\stack9560\Setup.hs --builddir=.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\ build exe:gs --ghc-options -hpcdir .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\hpc.hpc\ -ddump-hi -ddump-to-file
Process exited with code: ExitFailure 1

I hope I'm doing something wrong and someone will confirm this patch
works. Any ideas?

—
Reply to this email directly or view it on GitHub
#795 (comment)
.

[joozek78]

marcin at helios in /c/Users/marcin/dev/ghc on ghc-7.10
$ ghc --info
 [("Project name","The Glorious Glasgow Haskell Compilation System")
 ,("GCC extra via C opts"," -fwrapv")
 ,("C compiler command","$topdir/../mingw/bin/gcc.exe")
 ,("C compiler flags"," -fno-stack-protector")
 ,("C compiler link flags","")
 ,("Haskell CPP command","$topdir/../mingw/bin/gcc.exe")
 ,("Haskell CPP flags","-E -undef -traditional ")
 ,("ld command","$topdir/../mingw/bin/ld.exe")
 ,("ld flags","")
 ,("ld supports compact unwind","YES")
 ,("ld supports build-id","NO")
 ,("ld supports filelist","NO")
 ,("ld is GNU ld","YES")
 ,("ar command","$topdir/../mingw/bin/ar.exe")
 ,("ar flags","q")
 ,("ar supports at file","YES")
 ,("touch command","$topdir/touchy.exe")
 ,("dllwrap command","$topdir/../mingw/bin/dllwrap.exe")
 ,("windres command","$topdir/../mingw/bin/windres.exe")
 ,("libtool command","")
 ,("perl command","$topdir/../perl/perl.exe")
 ,("cross compiling","NO")
 ,("target os","OSMinGW32")
 ,("target arch","ArchX86_64")
 ,("target word size","8")
 ,("target has GNU nonexec stack","False")
 ,("target has .ident directive","True")
 ,("target has subsections via symbols","False")
 ,("Unregisterised","NO")
 ,("LLVM llc command","llc")
 ,("LLVM opt command","opt")
 ,("Project version","7.10.2.20150823")
 ,("Project Git commit id","19b32049e2061440a30448e3cdc6fe93e29b77fc")
 ,("Booter version","7.10.2")
 ,("Stage","2")
 ,("Build platform","x86_64-unknown-mingw32")
 ,("Host platform","x86_64-unknown-mingw32")
 ,("Target platform","x86_64-unknown-mingw32")
 ,("Have interpreter","YES")
 ,("Object splitting supported","YES")
 ,("Have native code generator","YES")
 ,("Support SMP","YES")
 ,("Tables next to code","YES")
 ,("RTS ways","l debug thr thr_debug thr_l  ")
 ,("Support dynamic-too","NO")
 ,("Support parallel --make","YES")
 ,("Support reexported-modules","YES")
 ,("Support thinning and renaming package flags","YES")
 ,("Uses package keys","YES")
 ,("Dynamic by default","NO")
 ,("GHC Dynamic","NO")
 ,("Leading underscore","NO")
 ,("Debug on","False")
 ,("LibDir","C:\\Users\\marcin\\local\\lib")
 ,("Global Package DB","C:\\Users\\marcin\\local\\lib\\package.conf.d")
 ]

[snoyberg]

Also, is the project you're trying to build open source by any chance? If
not, perhaps it would be possible to give me private access to it for
testing purposes.

On Tue, Aug 25, 2015, 9:59 PM Michael Snoyman michael@snoyman.com wrote:

Can you paste the output of ghc --info?

On Tue, Aug 25, 2015, 9:57 PM Marcin Goliński notifications@github.com
wrote:

:(

2015-08-25 18:53:09.8188472: [info] Linking .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\gs\gs.exe ... @(stack-0.1.3.1:Stack.Build.Execute src/Stack\Build\Execute.hs:905:35)
2015-08-25 18:53:09.9629436: [warn] gcc.exe: error: CreateProcess: No such file or directory @(stack-0.1.3.1:Stack.Build.Execute src/Stack\Build\Execute.hs:905:35)
2015-08-25 18:53:10.0209821: [warn] ghc: warning: _tzset from msvcrt is linked instead of __imp__tzset @(stack-0.1.3.1:Stack.Build.Execute src/Stack\Build\Execute.hs:905:35)

-- While building package greenticket-0.1.0.0 using:
C:\Users\marcin\local\bin\runhaskell.exe -package=Cabal-1.22.4.0 -clear-package-db -global-package-db -package-db=C:\Users\marcin\AppData\Roaming\stack\snapshots\x86_64-windows\lts-3.1\7.10.2.20150823\pkgdb\ C:\msys64\tmp\stack9560\Setup.hs --builddir=.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\ build exe:gs --ghc-options -hpcdir .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\hpc.hpc\ -ddump-hi -ddump-to-file
Process exited with code: ExitFailure 1

I hope I'm doing something wrong and someone will confirm this patch
works. Any ideas?

—
Reply to this email directly or view it on GitHub
#795 (comment)
.

[joozek78]

It's closed, I'll have to get a green light from my team. I don't believe anyone will object, but rules are rules

[joozek78]

@snoyberg I've added you

[snoyberg]

Alright, I just reproduced the problem, which I suppose is a good sign.

[snoyberg]

Well, here's an interesting data point: now gcc itself is printing this error:

>c:\Users\Michael\Documents\opt\ghc-7.10\mingw\bin\gcc.exe @c:\Users\Michael\AppData\Local\Temp\ghc13676_0\ghc_35.rsp
gcc.exe: error: CreateProcess: No such file or directory

This looks like gcc itself is unable to call out to other processes, because the arguments are too large. In fact, I can verify this by playing around with the response file enough and eventually getting an error message about being unable to call collect2. So now the trick is convincing gcc to call itself and its related tools with a response file... sigh.

[snoyberg]

OK, seems like we're not the first people to run into this, see:

http://sourceforge.net/p/mingw-w64/mailman/message/29339395/

So now the problem is that the gcc.exe shipped with GHC does not include this fix, which was introduced in 4.7.0 by the MinGW team. In theory, upgrading the gcc toolchain to something more recent will solve this problem.

[joozek78]

Well, naively replacing AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.2\mingw with version 4.9.3 from sourceforge didn't help

[snoyberg]

You'd need to do the mingw in /c/Users/marcin/dev/ghc/mingw to make it have an effect here.

[joozek78]

You mean I need both updated gcc and patched ghc?

[snoyberg]

Yes, both are required. We need GHC to use the response file to pass arguments to GCC, and GCC to use the response file for passing arguments to itself and to collect2.

[snoyberg]

In my testing, replacing the mingw directory with the one you linked to from Sourceforge does solve this problem. Can you confirm?

[snoyberg]

Also, it appears that GHC HEAD already has an updated version of GCC included, which presumably also has this fix in place. Backporting that change to the 7.10 branch will both be difficult and unlikely to be accepted upstream, so most likely our best bet at this point is to create an alternative bindist that has a modified mingw.

[joozek78]

Yeah, I confirm. I looked at ghc repo too :) Why do you think it won't be backported?

[snoyberg]

Because it's a big change in a point release. I'd recommend you raise an issue on the GHC trac and put a link back here. It would be ideal to get that in for GHC 7.10.3.

[joozek78]

I'll get that going. Thanks for helping me out!

[joozek78]

I've submitted task in ghc trac: https://ghc.haskell.org/trac/ghc/ticket/10795

[snoyberg]

Cool. Looks like I may have been mistaken and that patch can be back ported.

It's probably worth adding a comment explaining why
https://ghc.haskell.org/trac/ghc/ticket/10726 should be back ported

On Wed, Aug 26, 2015, 2:35 AM Marcin Goliński notifications@github.com
wrote:

I've submitted task in ghc trac:
https://ghc.haskell.org/trac/ghc/ticket/10795

—
Reply to this email directly or view it on GitHub
#795 (comment)
.

[snoyberg]

Once these two patches are merged to the 7.10 branch, I'm going to close this issue. Leaving open until then just in case the changes do not make it in 7.10.3, in which case we should provide an official way of getting an alternate bindist to users.

[snoyberg]

The patches are merged to both the 7.10 branch and HEAD, so I'm going to close this as resolved. However, there are not currently plans for a 7.10.3 release. I would recommend that those affected by this speak up on this thread:

http://mail.haskell.org/pipermail/glasgow-haskell-users/2015-September/026034.html

[themoritz]

I have been unsuccessful building and running the ghc 7.10 branch with the patches in place. Compiling ghc works without issues, but when running it, I get the following error message:

ghc.exe: internal error: checkProddableBlock: invalid fixup in runtime linker: 00000000086fbe98
    (GHC version 7.10.2.20150906 for x86_64_unknown_mingw32)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Here is what I did:

I followed this guide on building ghc on Windows 64bit using MSYS2: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

After cloning the repo, I ran ./boot and ./configure to get the windows tarballs. Then I checked out the ghc-7.10 branch (commit 108e35ff) and ran git submodule update --recursive before running ./boot ./configure again, and then make install.

Here is the output of ghc --info for the compiled ghc:

$ /usr/local/ghc-7.10/bin/ghc --info
 [("Project name","The Glorious Glasgow Haskell Compilation System")
 ,("GCC extra via C opts"," -fwrapv")
 ,("C compiler command","$topdir/../mingw/bin/gcc.exe")
 ,("C compiler flags"," -fno-stack-protector")
 ,("C compiler link flags","")
 ,("Haskell CPP command","$topdir/../mingw/bin/gcc.exe")
 ,("Haskell CPP flags","-E -undef -traditional ")
 ,("ld command","$topdir/../mingw/bin/ld.exe")
 ,("ld flags","")
 ,("ld supports compact unwind","YES")
 ,("ld supports build-id","YES")
 ,("ld supports filelist","NO")
 ,("ld is GNU ld","YES")
 ,("ar command","$topdir/../mingw/bin/ar.exe")
 ,("ar flags","q")
 ,("ar supports at file","YES")
 ,("touch command","$topdir/touchy.exe")
 ,("dllwrap command","$topdir/../mingw/bin/dllwrap.exe")
 ,("windres command","$topdir/../mingw/bin/windres.exe")
 ,("libtool command","")
 ,("perl command","$topdir/../perl/perl.exe")
 ,("cross compiling","NO")
 ,("target os","OSMinGW32")
 ,("target arch","ArchX86_64")
 ,("target word size","8")
 ,("target has GNU nonexec stack","False")
 ,("target has .ident directive","True")
 ,("target has subsections via symbols","False")
 ,("Unregisterised","NO")
 ,("LLVM llc command","llc")
 ,("LLVM opt command","opt")
 ,("Project version","7.10.2.20150906")
 ,("Project Git commit id","108e35ff67586ffd570ca18d84a4f5fbf79727cc")
 ,("Booter version","7.8.4")
 ,("Stage","2")
 ,("Build platform","x86_64-unknown-mingw32")
 ,("Host platform","x86_64-unknown-mingw32")
 ,("Target platform","x86_64-unknown-mingw32")
 ,("Have interpreter","YES")
 ,("Object splitting supported","YES")
 ,("Have native code generator","YES")
 ,("Support SMP","YES")
 ,("Tables next to code","YES")
 ,("RTS ways","l debug thr thr_debug thr_l thr_p ")
 ,("Support dynamic-too","NO")
 ,("Support parallel --make","YES")
 ,("Support reexported-modules","YES")
 ,("Support thinning and renaming package flags","YES")
 ,("Uses package keys","YES")
 ,("Dynamic by default","NO")
 ,("GHC Dynamic","NO")
 ,("Leading underscore","NO")
 ,("Debug on","False")
 ,("LibDir","C:\\msys64\\usr\\local\\ghc-7.10\\lib")
 ,("Global Package DB","C:\\msys64\\usr\\local\\ghc-7.10\\lib\\package.conf.d")
 ]

Here is the output of gcc --version:

$ /usr/local/ghc-7.10/mingw/bin/gcc --version
realgcc.exe (Rev3, Built by MSYS2 project) 5.2.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Any ideas what I may have done wrong? / Can you give me hints on how you compiled ghc (which git commit, etc.)?

[joozek78]

Sorry, I currently don't have time for full response, but I do remember
that happy, alex and cabal had to be in compatible versions, so maybe check
those first.

On Mon, 21 Sep 2015 at 12:04 Moritz Drexl notifications@github.com wrote:

I have been unsuccessful building and running the ghc 7.10 branch with the
patches in place. Compiling ghc works without issues, but when running it,
I get the following error message:

ghc.exe: internal error: checkProddableBlock: invalid fixup in runtime linker: 00000000086fbe98
(GHC version 7.10.2.20150906 for x86_64_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug

Here is what I did:

I followed this guide on building ghc on Windows 64bit using MSYS2:
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

After cloning the repo, I ran ./boot and ./configure to get the windows
tarballs. Then I checked out the ghc-7.10 branch (commit 108e35ff) and ran git
submodule update --recursive before running ./boot ./configure again, and
then make install.

Here is the output of ghc --info for the compiled ghc:

$ /usr/local/ghc-7.10/bin/ghc --info
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("GCC extra via C opts"," -fwrapv")
,("C compiler command","$topdir/../mingw/bin/gcc.exe")
,("C compiler flags"," -fno-stack-protector")
,("C compiler link flags","")
,("Haskell CPP command","$topdir/../mingw/bin/gcc.exe")
,("Haskell CPP flags","-E -undef -traditional ")
,("ld command","$topdir/../mingw/bin/ld.exe")
,("ld flags","")
,("ld supports compact unwind","YES")
,("ld supports build-id","YES")
,("ld supports filelist","NO")
,("ld is GNU ld","YES")
,("ar command","$topdir/../mingw/bin/ar.exe")
,("ar flags","q")
,("ar supports at file","YES")
,("touch command","$topdir/touchy.exe")
,("dllwrap command","$topdir/../mingw/bin/dllwrap.exe")
,("windres command","$topdir/../mingw/bin/windres.exe")
,("libtool command","")
,("perl command","$topdir/../perl/perl.exe")
,("cross compiling","NO")
,("target os","OSMinGW32")
,("target arch","ArchX86_64")
,("target word size","8")
,("target has GNU nonexec stack","False")
,("target has .ident directive","True")
,("target has subsections via symbols","False")
,("Unregisterised","NO")
,("LLVM llc command","llc")
,("LLVM opt command","opt")
,("Project version","7.10.2.20150906")
,("Project Git commit id","108e35ff67586ffd570ca18d84a4f5fbf79727cc")
,("Booter version","7.8.4")
,("Stage","2")
,("Build platform","x86_64-unknown-mingw32")
,("Host platform","x86_64-unknown-mingw32")
,("Target platform","x86_64-unknown-mingw32")
,("Have interpreter","YES")
,("Object splitting supported","YES")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Tables next to code","YES")
,("RTS ways","l debug thr thr_debug thr_l thr_p ")
,("Support dynamic-too","NO")
,("Support parallel --make","YES")
,("Support reexported-modules","YES")
,("Support thinning and renaming package flags","YES")
,("Uses package keys","YES")
,("Dynamic by default","NO")
,("GHC Dynamic","NO")
,("Leading underscore","NO")
,("Debug on","False")
,("LibDir","C:\msys64\usr\local\ghc-7.10\lib")
,("Global Package DB","C:\msys64\usr\local\ghc-7.10\lib\package.conf.d")
]

Here is the output of gcc --version:

$ /usr/local/ghc-7.10/mingw/bin/gcc --version
realgcc.exe (Rev3, Built by MSYS2 project) 5.2.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Any ideas what I may have done wrong? / Can you give me hints on how you
compiled ghc (which git commit, etc.)?

—
Reply to this email directly or view it on GitHub
#795 (comment)
.

[themoritz]

I have

• Cabal-install 1.22.6.0 (with cabal 1.22.4.0)
• Alex 3.1.4
• Happy 1.19.5

Where do I check that they are compatible?

[rubenmoor]

Current status of this issue from my perspective:

• Theoretically, a ghc-7.10.3 might be released with the patch that solves this issue (I have no idea when this would be), or even longer term: the next major ghc release contains the patch
• @joozek78 has provided a bindist that should solve the issue, however, we failed to compile our project (compile, not link), the offending package being wai-app-static
• We did not manage to build our own working ghc (our ghc failed earlier during compliation than @joozek78's bindist)

I would be very interested, if anyone else was more successful.

[kejace]

Seeing that GHC 7.10.3 RC 1 has been released, how do I go about testing stack with this version of GHC?

https://mail.haskell.org/pipermail/ghc-devs/2015-November/010310.html

[mgsloan]

@kejace It should literally be as easy as installing it to your system, such that it's on the PATH. Stack will then default to prefering it over 7.10.2. See this comment for more info.