[nhc-bugs] Re: problems installing nhc98-1.04 on cygwin

[C.Reinke]

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