Hi Malcolm, [Win32 fun with case-sensitive filenames deleted]
In case you can't imagine this kind of silly behaviour, and just to confirm that I'm not hallucinating and that the FAQ is not simply out of date, here is an example ...
Ok, ok, I believe you. So you know already what the fix for this bug is - get a /real/ operating system, not a toy! :-)
Hmm, standard disclaimers aside, NT4 was getting so close to a really operating system that I still have some hope that its successors might some day reach the quality of its *nixish predecessors.. Moreover, cygwin took on a red hat a while ago, and cygwin on NT is not a bad compromise (in this particular case, if you followed the reference I gave, cases are preserved in the file system, but too many windows tools don't know what to do with them, so the cygwin developers considered it too dangerous to encourage case-sensitive file names). Still, I was afraid of spreading misinformation when I first saw those comments, hence all the references and experiments:-)
Ok, I think you have persuaded us to use one different suffix. We are currently thinking of changing 't' (for time profiling) to 'z' in your honour. (For 'zeit', or perhaps for your middle name Claus?).
Thank you, your honour. I'm not aware of having a middle name (a certain cs-support team at an unnamed English university was once unable to cope with this idea and decided to add a z to my then-email-address;-). But as we use time profiling when our programs seem to go to sleep (zzzz...), that suffix seems appropriate. Back to bugs: - The tar-file still seems (not) to contain a spurious file: $ tar xvzf //e/archive/software/nhc98src-1.04.tar.gz >tar.log tar: nhc98-1.04/src/prelude/Numeric/Makefile?: Could not create file: No such file or directory tar: Error exit delayed from previous errors - There seems to be a disagreement about the order in which libraries are processed during linking. Old gcc man page says: " The linker handles an archive file by scanning through it for members which define symbols that have so far been referenced but not defined. " In other words, adding -lncurses as *the very first flag* in a call to gcc ain't going to help anyone. In src/tracer/hat/Makefile: LINKFLAGS= -lncurses -g This is used just after $(CC) in the targets.. Two of the targets also use a variable $(ncurses), which doesn't seem to be defined. Suggested fix (seems to work for me): - define ncurses as -lncurses (and remove -lncurses from LINKFLAGS) - add $(ncurses) to end of hat-detect target - for consistency, NCURSES would make more sense And finally, a question: I was under the impression that nhc supported addFinalizer, but I can't seem to find it anywhere. Is it supported, and if so, where do I find it? Cheers, Claus