| 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

Yes, I guess this looks a little strange - but it works here. Are you saying it doesn't work in Cygwin? Nevertheless, you are right, we ought to change it.

The fragment of man-page I was quoting (search archives as they occur, for currently outstanding references only) actually stems from our gcc on Solaris installation, but it looks the same for the gcc on cygwin version, and for the Solaris ld version, and I assume it would be standard behaviour. To answer your question, cygwin's gcc failed on the linking operation in question when lncurses was given at the start, and succeeded when it was given at the end. Perhaps (some) Linuxes support a more convenient behaviour for simple cases? That would be a nice trap for portable development..

We do not support any operation called addFinalizer. However, we do have

FFI.newForeignObj :: FFI.Addr -> IO () -> IO FFI.ForeignObj

Is this sufficient for your purposes?

Unfortunately not. The idea, as mentioned briefly in our meeting, a few weeks ago, was to use the (older?) addFinalizer as a hook into the memory management, enabling GHood to show when parts of an observed data structure get garbage collected. Hugs and GHC support (supported?) such an operation, built around weak pointers, but both implement optimisations that tend to move data around, causing finalizers for anything but foreign addresses to be run at completely unsuitable moments. I had already given up on this idea, but Colin suggested that I might have more luck with nhc, as you have to be more careful with such things, to support some of your profiling tools. Well, it was not meant to be, and accepting finalizers only for those objects for which they will actually be run at the "right" moment is probably the more honest approach. Would have been nice and really useful, though.. Regards, Claus