stack build network on Windows via Cygwin SSH fails where cabal install network succeeds

[acfoltzer]

So, right out of the gate, I know that Cygwin is not an officially supported build environment for network. However, what we do on some of our CI servers is use Cygwin only for the ssh support, and then make sure that the msys binaries come before Cygwin's in the PATH.

On a Windows 10 machine with MinGHC 7.10.2 installed, I can put MinGHC's msys binaries in the path:

[...]/cygdrive/c/Users/hudson/AppData/Local/Programs/minghc-7.10.2-x86_64/ghc-7.10.2/bin:/cygdrive/c/Users/hudson/AppData/Local/Programs/minghc-7.10.2-x86_64/bin:/cygdrive/c/Users/hudson/AppData/Local/Programs/minghc-7.10.2-x86_64/ghc-7.10.2/mingw/bin[...]

With the path configured thusly, the following Just Works:

cabal install network --configure-option --build=x86_64-pc-msys --configure-option --host=x86_64-pc-msys

However, I cannot seem to find an invocation of stack that works in this same environment. My first thought is that stack build needs a way to pass along runhaskell Setup.hs configure options, but maybe there's something else going on with paths?

[acfoltzer]

It'd probably help to include how stack build network fails:

Configuring network-2.6.2.1...
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
checking build system type... i686-pc-msys
checking host system type... i686-pc-msys
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/tmp/stack3424/network-2.6.2.1':
configure: error: C compiler cannot create executables
See `config.log' for more details

[acfoltzer]

Found out a workaround for now by gleaning the output of stack install -v network. I copied the invocation of the Setup.hs configure step, manually added the ghc-7.10.3/bin and ghc-7.10.3/mingw/bin directories to my PATH, and then:

$ runhaskell Setup.hs configure --with-ghc='C:\Users\hudson\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\bin\ghc.exe' --with-ghc-pkg='C:\Users\hudson\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\bin\ghc-pkg.exe' --user
 --package-db=clear --package-db=global --package-db='C:\Users\hudson\AppData\Roaming\stack\snapshots\475e77f9\pkgdb' --libdir='C:\Users\hudson\AppData\Roaming\stack\snapshots\475e77f9\lib' --bindir='C:\Users\hudson\AppData\Roaming\stack\
snapshots\475e77f9\bin' --datadir='C:\Users\hudson\AppData\Roaming\stack\snapshots\475e77f9\share' --libexecdir='C:\Users\hudson\AppData\Roaming\stack\snapshots\475e77f9\libexec' --sysconfdir='C:\Users\hudson\AppData\Roaming\stack\snapsho
ts\475e77f9\etc' --docdir='C:\Users\hudson\AppData\Roaming\stack\snapshots\475e77f9\doc\network-2.6.2.1' --htmldir='C:\Users\hudson\AppData\Roaming\stack\snapshots\475e77f9\doc\network-2.6.2.1' --haddockdir='C:\Users\hudson\AppData\Roamin
g\stack\snapshots\475e77f9\doc\network-2.6.2.1' --dependency=base=base-4.8.2.0-14035a44a8b95c6832da6dae1420f59e --dependency=bytestring=bytestring-0.10.6.0-342400f3bb78fee60dde2cecf10f8e3b --extra-include-dirs='C:\Users\hudson\AppData\Loc
al\Programs\stack\x86_64-windows\msys2-20150512\mingw32\include' --extra-include-dirs='C:\Users\hudson\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include' --extra-lib-dirs='C:\Users\hudson\AppData\Local\Programs\st
ack\x86_64-windows\msys2-20150512\mingw32\lib' --extra-lib-dirs='C:\Users\hudson\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib' --configure-option --build=x86_64-pc-msys

After this, the Setup.hs build, Setup.hs copy, and Setup.hs register steps worked great, and then a subsequent stack install cabal-install worked fine without trying to rebuild network.

So, it looks like all I'd need for this ticket is a way to pass extra arguments to the Setup.hs configure step during a stack build.

[mgsloan]

Yeah, that's tracked by #1438

PRs welcome! It should be a pretty easy change. Seems there's a fair amount of demand for this, and I wanted it myself recently (for --disable-library-stripping), so if someone else doesn't do it, I'll probably implement sometime in the next couple weeks.

Thanks for the level of detail in this report! Closing it out as a duplicate, since it's covered by the issue linked above.

[mgsloan]

Re-opening this as it's come up again #2169 , and I thought #1438 would get implemented soon. Quite a bit of progress has been made towards #1265 , and I think we want to see how that works out before adding another thing that works similarly to flags / ghc-options.

[jwaldmann]

possibly related (same error, but on linux-i386): http://stackoverflow.com/questions/37354416/stack-cannot-build-network-wheres-config-log

[vagarenko]

I have a similar problem. Cabal from Haskell Platform 8.0.1 installs network fine, while stack fails:

> stack install network --resolver nightly

[1 of 1] Compiling Main             ( C:\Users\alex\AppData\Local\Temp\stack632\network-2.6.2.1\Setup.hs, C:\Users\alex\AppData\Local\Temp\stack632\network-2.6.2.1\.stack-work\dist\b7fec021\setup\Main.o )
Linking C:\Users\alex\AppData\Local\Temp\stack632\network-2.6.2.1\.stack-work\dist\b7fec021\setup\setup.exe ...
Configuring network-2.6.2.1...
setup: The package has a './configure' script. If you are on Windows, This
requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. If you
are not on Windows, ensure that an 'sh' command is discoverable in your path.

My global cabal config has these fields:

extra-include-dirs: C:\Program Files\Haskell Platform\8.0.1\mingw\include
extra-lib-dirs: C:\Program Files\Haskell Platform\8.0.1\mingw\lib
extra-prog-path: C:\Program Files\Haskell Platform\8.0.1\msys\usr\bin

Does stack have similar config options?

[gbaz]

Came here via the referenced ticket. I tried to find some way to work around this elsewhere, but it looks like the "right" place to fix this is definitely by adding an option to stack. I'd suggest one extra feature if you're at it. Given that stack obviously can find the system ghc, it would be nice if it could check if there are mingw and msys directories "up and over" from it so that it could autodiscover the appropriate directories when using the system ghc as they'll likely always be in the same relative structure. This seems preferable and relatively self-contained as an option.

[mittenchops]

I'm having this issue too on a new install. Can't get stack install network to run---claims the C compiler cannot create executables, but it's right there in mingw\bin\gcc.exe

Was interested in using @acfoltzer 's fix.

[liskin]

I also have this issue but I'm certain it's this: https://neilmitchell.blogspot.cz/2016/12/installing-haskell-network-library-on.html and the fix is this: haskell/cabal@3c1b619
@ndmitchell claims stack fixes this but it doesn't. It just maybe happened to not trigger this bug since stack puts GHC in a different directory. But I need stack run as my user to use the same GHC as the stack running as jenkins slave, so stack setup isn't an option. With ghc in C:\hsplatform\ghc-8.0.1, this happens every time. :-(

[gbaz]

@liskin @mittenchops the latest stack binary, if you upgrade, should have #2552 merged in which should fix this. If that doesn't work, let me know and I could provide a few other suggestions.

[liskin]

@gbaz I don't see how #2552 is relevant to mishandling of short path names. That being said, the 1.3.2 binary I downloaded yesterday doesn't work. Anyway, I worked it around by uninstalling GHC and installing it back into C:\hsplatform\ghc-8_0_1.

[gbaz]

Oh -- sorry I misread and didn't follow the link. sloppy on my part! Indeed that fixed a different issue (the original reported on this thread), not the short path name regression. I suppose a stack built against the very latest release of the Cabal library (which has that patch you link) may fix this. Either way, glad you found a workaround.

[liskin]

Yeah, I'm sorry for being slightly offtopic. I hoped I might help @mittenchops as I assumed everything except the shortpath thing would be fixed by now. :-)

[OnurGumus]

I worked it around by adding
C:\Program Files\Haskell Platform\8.0.1\msys\usr\bin
to path.