[nhc-bugs] Building nhc98 on Windows 2000

[C.Reinke]

> 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 <sys/types.h>      instead
> 
> Ok, I could place some more #ifdefs to solve this.
> 
> >     in include/HsFFI.h: 
> >       #include <sys/types.h>      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..

<sys/types.h> 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