Yes, it is still possible to build with a specified compiler, overriding the detected choice of compiler, e.g. ./configure --buildwith=gcc

Ok, tried that (with the patches and with the include-modifications). It seems to run into a problem as well (haven't had time to look into this yet, but just in case you recognise the symptoms): cd src/hmake; make fromC config make[1]: Entering directory `/tmp/nhc98-1.12/src/hmake' mkdir -p /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake || /bin/true /tmp/nhc98-1.12/script/nhc98 -H4M -o /tmp/nhc98-1.12/lib/ix86-CYGWIN_NT-5.0/Mk Prog.exe -d /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake QSort.hc Unli t.hc Utils.hc Tsort.hc FileName.hc SymTab.hc Output.hc Order.hc ListUtil. hc Getmodtime.hc MkProg.hc IsPrefixOf.hc Compiler.hc PreProcessor.hc Argv. hc Graph.hc GetDep.hc ParseLib.hc Compat.hc Imports.hc Config.hc /tmp/nhc98-1.12/script/nhc98 -o /tmp/nhc98-1.12/lib/ix86-CYGWIN_NT-5.0/Ol der.exe -d /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake Older.hc /tmp/nhc98-1.12/script/nhc98 -o /tmp/nhc98-1.12/lib/ix86-CYGWIN_NT-5.0/MkCo nfig.exe -d /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake MkConfig.hc Co nfig.hc Compiler.hc strip /tmp/nhc98-1.12/lib/ix86-CYGWIN_NT-5.0/MkProg.exe /tmp/nhc98-1.12/lib/ix86 -CYGWIN_NT-5.0/Older.exe /tmp/nhc98-1.12/lib/ix86-CYGWIN_NT-5.0/MkConfig.exe sh /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/hmake3.config hmake-config: Warning: Config file not found: '/tmp/nhc98-1.12/lib/ix86-CYGWIN_NT-5.0/hmakerc' hmake-config: Starting new config from scratch. cannot create /tmp/hmakeconfig.1748: permission denied grep: /cygdrive/c/ghc/ghc-5.02.2/bin/ghc: No such file or directory I/O error (user-defined), call to function `userError': Command (grep '^libdir=' /cygdrive/c/ghc/ghc-5.02.2/bin/ghc | head -1 | sed 's /^libdir=.\(.*\)./\1/') failed grep: /cygdrive/c/ghc/ghc-5.02.2/bin/ghc: No such file or directory cannot create /tmp/hmakeconfig.1840: permission denied I/O error (user-defined), call to function `userError': Command (grep '^libdir=' /cygdrive/c/ghc/ghc-5.02.2/bin/ghc | head -1 | sed 's /^libdir=.\(.*\)./\1/') failed cannot create /tmp/hmakeconfig.1120: permission denied I/O error (user-defined), call to function `userError': Command (grep ^NHC98INCDIR /tmp/nhc98-1.12/script/nhc98| cut -c27- | cut -d'}' -f1) failed hmake-config: compiler not known: '/tmp/nhc98-1.12/script/nhc98' make[1]: *** [config] Error 2 make[1]: Leaving directory `/tmp/nhc98-1.12/src/hmake' make: *** [targets/ix86-CYGWIN_NT-5.0/hmake-gcc] Error 2

...

- inttypes.h and stdint.h don't exist #include instead

Ok, I could place some more #ifdefs to solve this.

...

in include/HsFFI.h: #include instead, and typedef uint{8,16,32,64}_t yourself

... but `uint8_t' etc. are part of the C standard now are they not?

I don't have the standard here, but the way I read the draft (N843, see first links at http://www.lysator.liu.se/c/ ), you seem to be right - they should be in stdint.h, which doesn't exist in cygwin (but has been added to mingw). Someone asked about this discrepancy on the cygwin mailing lists a while ago, but I can't see an answer.. defines the signed versions (intN_t), and a variant of the unsigned versions (u_intN_t), protected by "#ifdef __MS_types_". If you really only need the four typedefs, perhaps it is safest to define them yourself in the __CYGWIN32__ case, until cygwin catches up?

There must be a standard include for them.

"should"?-)

...

ghc -package lang -package posix -c -o /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/QSort.o QSort.hs Assembler messages: FATAL: Can't create \tmp\nhc98-1.12\targets\ix86-CYGWIN_NT-5.0\obj\hmake\QSort.o: No such file or directory

I *think* the problem here is that the standard GHC distribution for Windows is now a mingw32 application, and it translates paths to "native" format, which apparently the Cygwin assembler doesn't like. Sigbjorn has recently made a GHC-for-Cygwin binary package available which might solve this problem.

Tracking a separate (no-thrills) version of GHC-for-Cygwin just to compile nhc doesn't sound attractive, though I applaud Sigbjorn's efforts for those who don't have another route. As I mentioned, cygwin and ghc are flexible enough to work around this problem by choosing appropriate prefixes to those absolute paths affected.

...

[I thought these ghc/cygwin-path problems were an old Hat by now?-]

So did I, but GHC's move away from Cygwin to support a native Windows configuration seems to have broken several things that used to work.

Yeah, "never change a winning team", they say. On the one hand, I can see the attraction of getting closer to stand-alone executables. On the other hand, going from a relatively complete system (cygwin) to a minimalist one (mingw) has its disadvantages, such as

...

c:\ghc\ghc-5.02.2\gcc-lib\ld.exe: cannot find -lHSposix

My fault. I assumed that GHC's -package posix would be available in all current GHC's. But of course, Windows is a non-Posix environment.

Well, cygwin has good posix support, but mingw (on which ghc relies now) hasn't. There you go.. http://www.mingw.org/x86-win32-ports.shtml

I'll try to find a simple fix that removes the Posix dependency under Windows - it is only used in a trivial way anyhow.

Sounds like the way to go? I will look into the buildwith=gcc problems another time. Let me know when you've got an idea about the posix part, and I'll try buildwith=ghc again. Cheers, Claus