Hi Claus,
here's my problem log so far (btw, configure found my ghc-5.02.2; there used to be a way to install with gcc only - is this still there?):
Yes, it is still possible to build with a specified compiler, overriding the detected choice of compiler, e.g. ./configure --buildwith=gcc
- 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? There must be a standard include for them.
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.
[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.
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. I'll try to find a simple fix that removes the Posix dependency under Windows - it is only used in a trivial way anyhow. Regards, Malcolm