Atze Dijkstra
$(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