[Hat] Hat install problem

[Malcolm Wallace]

Atze Dijkstra <atze@cs.uu.nl> writes:

> >     $(OBJDIR)/TPreludeBuiltinTypes.o: $(OBJDIR)/Hat.o
> 
> Hmn, I found an already made 'hat.o'. The MacOSX HFS+ file system is 
> (sometimes) case insignificant.

Ugh.  I believe that various Windows filesystems suffer from the same
wart, i.e. that "ABC" and "abc" are treated as the same filename.
So this isn't really a bug in GNUmake at all, but a design flaw in
the HFS+ filesystem.

As a permanent workaround, we could rename one or both of the
hat.c/Hat.hs modules so that the object files do not conflict.

> now the build stops with an internal error:
> 
> nhc98 +RTS -K12M -H64M -RTS   -cpp -c -o 
>   /Volumes/Apps/Install/hat-2.00/targets/powerpc-Darwin-6.1/obj/hatlib/...
>   .../nhc98/TPreludeBasic.o TPreludeBasic.hs
> Fatal internal error:  StringTable data allocated too high in address space!
> gcc: /tmp/TPreludeBasic.21196.s: No such file or directory

OK, the "StringTable data" error is not one I recognise.  As far as
I can tell, it is not produced by nhc98, nor gcc, nor ghc's runtime
system (if you compiled nhc98 with ghc).  Maybe it is part of some
Darwin-only library?  Try

    strings $comp | grep StringTable

on each of the possible compilers (the actual executable binary,
not the driver script), e.g.
    /usr/bin/gcc-2.95.2,
    /usr/local/lib/nhc98/powerpc-Darwin-6.1/nhc98comp
    /usr/local/lib/ghc-5.04/ghc-5.04
to determine where the message is coming from.  Maybe try looking
in the shell (/bin/bash?) as well.

Another line of attack is to re-run the nhc98 commandline that produced
the error, by hand, adding a `-v' flag to see what the driver script
is doing.

Regards,
    Malcolm