Re: [nhc-bugs] Building nhc98 on Windows 2000

I am not able to fully build nhc98 V1.12 under Windows 2000 (cygwin): building hmake constantly fails.
just gave it a quick try (cygwin,Win2k,nhc-1.12+ranlib/hmake-patches).
I was able to work around several other problems: a) inclusion of stdint.h (which gave name conflicts),
only exists in mingw part (no experience with that, not sure whether its a good idea to include its version of stdint.h?)
b) inclusion of inttypes.h (this file is not even present) and
doesn't exist in cygwin.
Could you supply some more details, particularly about how you worked around problems (a) and (b)? The only reason for #include'ing those files is to get the standard typedef for int64_t etc. Is there an alternative location for that in Cygwin?
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?):
- inttypes.h and stdint.h don't exist
in src/runtime/kernel/mark.h:
#include

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
participants (2)
-
C.Reinke
-
Malcolm Wallace