Compiling Haskell code in Cygwin, and some other bugs in Haskell Platform on Windows

Question

I am trying to compile a simple hello world program in Haskell, with Haskell Platform 2011.2.0.1. If I load the code in WinGHCi, and use the GUI to compile, the .exe is created. Then I can run the .exe from Cygwin.

But if I try to compile the code in Cygwin (using ghc --make), linker fails. But again, if I compile from the Windows cmd prompt, then the compile+linker works fine.

Are there any other environment variables I need to import into Cygwin, to make the compile+linker work in it? I have put the following dirs in my Cygwin PATH: 2011.2.0.1/lib/extralibs/bin, 2011.2.0.1/bin (these are the only two valid Haskell related entries that I could see in the Windows environment variables).

I also noticed a couple of invalid items in the Windows environment variables (this looks like a bug in the Haskell installation):

1. (system var) C/ProgramFiles/Haskell/bin - this dir does not exist because I have installed Haskell in D disk.
2. (user var) userxxx/ApplicationData/cabal/bin - this dir does not exist.

I tried to file a bug report in HaskellPlatform, but I dont have permission to do it.

Answer 1

Without access to your development environment or a listing of the errors that you're getting, I can only assume that the issue is related to the way that you've set up your PATH.

GHC on Windows comes bundled with its own gcc compiler (for C code) and ld linker. If you've installed Cygwin, you've probably also installed the MinGW toolchain, which comes with its own version of gcc and ld. Then, you've probably made your PATH variable list /usr/bin before the path to the Haskell Platform binary directories, which makes ghc find the MinGW linker and C compiler before it finds the versions that were bundled with GHC.

You need to make sure that the HP directories are listed before the Cygwin directories. It should not be like this:

$ echo $PATH
/bin:/usr/bin:.../2011.2.0.1/bin

Instead, it should be like this:

$ echo $PATH
.../2011.2.0.1/bin:/bin:/usr/bin

This is only a guess at what the issue might be, and you should provide more details for a better diagnosis.