Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
rubenmoor opened this issue Aug 15, 2015 · 49 comments

Comments

Projects
None yet
7 participants
@rubenmoor
Copy link
Contributor

commented Aug 15, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 16, 2015

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

This comment has been minimized.

Copy link

commented Aug 17, 2015

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 snoyberg changed the title Could not execute: .../gcc.exe Overlong command line arguments on Windows WAS Could not execute: .../gcc.exe Aug 17, 2015

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Aug 17, 2015

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 snoyberg added this to the 0.3.0.0 milestone Aug 17, 2015

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Aug 17, 2015

@themoritz

This comment has been minimized.

Copy link

commented Aug 17, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 17, 2015

@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

This comment has been minimized.

Copy link
Contributor

commented Aug 17, 2015

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

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Aug 18, 2015

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

This comment has been minimized.

Copy link

commented Aug 20, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2015

How about:

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

This comment has been minimized.

Copy link

commented Aug 20, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2015

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

@joozek78

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

:(

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

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

@snoyberg I've added you

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

@joozek78

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

You mean I need both updated gcc and patched ghc?

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

@joozek78

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

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

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Aug 26, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 27, 2015

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 snoyberg added the blocked label Aug 27, 2015

@snoyberg snoyberg self-assigned this Aug 27, 2015

@snoyberg snoyberg modified the milestones: Later improvements, 0.3.0.0 Sep 6, 2015

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2015

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

@snoyberg snoyberg closed this Sep 16, 2015

@themoritz

This comment has been minimized.

Copy link

commented Sep 21, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Sep 21, 2015

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

This comment has been minimized.

Copy link

commented Sep 21, 2015

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

This comment has been minimized.

Copy link
Contributor Author

commented Sep 29, 2015

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

This comment has been minimized.

Copy link

commented Nov 3, 2015

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

This comment has been minimized.

Copy link
Collaborator

commented Nov 4, 2015

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.