- Nhc-bugs - Haskell.org

Re: [nhc-bugs] problems installing nhc98-1.04 on cygwin
by C.Reinke 29 May '01

29 May '01

> | 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

1 0

Re: [nhc-bugs] Re: problems installing nhc98-1.04 on cygwin
by C.Reinke 29 May '01

29 May '01

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

2 1

nhc -T problem
by Malcolm Wallace 25 May '01

25 May '01

[ Moved from nhc-users to nhc-bugs ] Wojciech Moczydlowski, Jr writes: > I've just installed nhc 1.04, and tried to execute: hmake 1 -T > in a directory containing file 1.hs: > and I've got the following error message: > > [khaliff@90-mia-3 khaliff]$ hmake 1 -T > nhc98 -T -c -o 1.T.o 1.hs > nhc98 -T -o 1 1.T.o > 1.T.o(.data+0x1a8): undefined reference to N_Prelude_46mkNTId' > 1.T.o(.data+0x1b0): undefined reference to N_Prelude_46mkSR' > 1.T.o(.data+0x1b8): undefined reference to N_Prelude_46mkTNm' > 1.T.o(.data+0x1bc): undefined reference to F_Prelude_46mkTRoot' > 1.T.o(.data+0x1e8): undefined reference to N_Prelude_46lazySat' > 1.T.o(.data+0x310): undefined reference to N_Prelude_46mkNTId' > 1.T.o(.data+0x318): undefined reference to N_Prelude_46mkSR' > 1.T.o(.data+0x320): undefined reference to N_Prelude_46mkTNm' > 1.T.o(.data+0x324): undefined reference to F_Prelude_46mkTRoot' > 1.T.o(.data+0x364): undefined reference to N_Prelude_46lazySat' We have not been able to reproduce this problem. Can you identify which processor/OS you are using? The missing symbol names look suspicious; . they should not have a quote ' character at the end . the N_ prefix should be FN_ . the F_ prefix should be CF_ It is possible that the problem is due to using a strange linker - can you tell whether it is Gnu ld (via gcc) or some other linker? One experiment that might fix the problem is to edit the script/nhc98.inst shell script. Line 530 is: LDLIBS=$MAINROUTINE" "$NHC98LIBDIR/$MACHINE/mutlib$CFG.o" "$NHC98LIBDIR/$MACHINE/mutator$CFG.o" "$NHC98LIBDIR/$MACHINE/Prelude$CFG.a" "$NHC98LIBDIR/$MACHINE/Runtime$CFG.a" "$NHC98LIBDIR/$MACHINE/Prelude$CFG.a" "$NHC98LIBDIR/$MACHINE/libdebug$CFG.a" "$NHC98LIBDIR/$MACHINE/Runtime$CFG.a" "$NHC98LIBDIR/$MACHINE/Prelude$CFG.a" "$NHC98LIBDIR/$MACHINE/Runtime$CFG.a Try adding another " "$NHC98LIBDIR/$MACHINE/Prelude$CFG.a to the end of this line, and maybe another " "$NHC98LIBDIR/$MACHINE/Runtime$CFG.a also. Afterwards, you must run ./configure again to re-generate the actual runnable script/nhc98. Regards, Malcolm

3 4

<Pine.LNX.4.10.10105222334140.24464-100000@90-mia-3.acn.waw.pl>
by Malcolm Wallace 24 May '01

24 May '01

[ Moved from nhc-users to nhc-bugs ] Wojciech Moczydlowski, Jr writes: > The configure script fails to detect ghc-5.00 - due to driver changes. Oops, yes indeed. Try the following patch. I haven't been able to test it fully, but i think it should work. Regards, Malcolm ---- cut here ---- diff -u -r1.27 confhc --- script/confhc 2001/03/23 20:36:38 1.27 +++ script/confhc 2001/05/23 13:25:21 @@ -149,12 +149,18 @@ whichGHC=`which ghc` GHCVER=`${whichGHC} --version 2>&1 | sed 's/^.*version[ ]*$[0-9.]*$.*/\1/'` GHCSYM=`echo $GHCVER | tr "." " " | ( read x y z; echo $x$y; )` - GHCDIR=`grep '^\$libdir=' ${whichGHC} | head -1 | sed 's/^\$libdir=[^/]*$.*$.;/\1/'` - if [ -d $GHCDIR/imports ] - then GHCINCDIR=$GHCDIR/imports - elif [ -d $GHCDIR/lib/imports ] - then GHCINCDIR=$GHCDIR/lib/imports - else GHCDIR="" + if [ $GHCSYM -lt 500 ] + then + GHCDIR=`grep '^\$libdir=' ${whichGHC} | head -1 | sed 's/^\$libdir=[^/]*$.*$.;/\1/'` + if [ -d $GHCDIR/imports ] + then GHCINCDIR=$GHCDIR/imports + elif [ -d $GHCDIR/lib/imports ] + then GHCINCDIR=$GHCDIR/lib/imports + else GHCDIR="" + fi + else + GHCDIR=`${whichGHC} --show-package std --field import_dirs` + GHCINCDIR=`dirname $GHCDIR` fi fi if [ "$GHCDIR" = "" ] @@ -247,7 +253,8 @@ 2.*) sed -e "s|^GHC=0$|GHC=3|" ;; 3.*) sed -e "s|^GHC=0$|GHC=4|" ;; 4.*) sed -e "s|^GHC=0$|GHC=5|" ;; - *) sed -e "s|^GHC=0$|GHC=6|" ;; + 5.*) sed -e "s|^GHC=0$|GHC=6|" ;; + *) sed -e "s|^GHC=0$|GHC=7|" ;; esac ) fi

2 4

Cygwin Build Bug (Probably Affects other GNU GLIBC Builds)
by Brent Fulgham 24 May '01

24 May '01

For thread-safety reasons, the GNU C Library (2.2+) defines "errno" as a macro that calls a function to get the errno of the current thread. Consequently, the source file "src/runtime/Builtin/cIOExtras.c" needs to include the <errno.h> header file, rather than declaring an extern variable. Diff: ========================================================================== *** cIOExtras.old.c Wed May 23 14:54:58 2001 --- cIOExtras.c Wed May 23 14:26:54 2001 *************** *** 1,10 **** /* basic unsafe utilities, defined in IOExtras */ #include "cinterface.h" #include "mk.h" void performGC () { C_GC(0); } int unsafePtrEq (void* a, void* b) { return (a==b); } /* basic error handling via C's errno */ ! extern int errno; int getErrNo (void) { return errno; } --- 1,11 ---- /* basic unsafe utilities, defined in IOExtras */ #include "cinterface.h" #include "mk.h" + #include "errno.h" void performGC () { C_GC(0); } int unsafePtrEq (void* a, void* b) { return (a==b); } /* basic error handling via C's errno */ ! /*extern int errno;*/ int getErrNo (void) { return errno; }

2 1

problems installing nhc98-1.04 on cygwin
by C.Reinke 23 May '01

23 May '01

Hi there, I'm trying to install the results of months of cooperative hacking, your all new nhc98-1.04, on cygwin (Windows/NT4). Apart from a missing "include <errno.h>" in cIOExtras.c, there seems to be a problem with suffixes, or a missing file, which has stopped me from finishing the installation. [nhc98-1.04, cygwin, NT4; configure +docs; make all] Errors encountered so far: -- [missing in nhc98-1.04\src\runtime\Builtin\cIOExtras.c] #include <errno.h> -- make[3]: Entering directory `/tmp/nhc98-1.04/src/prelude/Numeric' /tmp/nhc98-1.04/script/nhc98 -cpp -T -dbgtrans -trusted -P/tmp/nhc98-1.04/in clude -DTRACING -c +CTS -part -redefine -CTS -P../Char -P../PreludeText -P.. /PreludeList -P../Ratio -o /dev/null LexDigits.hs I/O error (user-defined), call to function `userError': Can't open any of: ./IsDigit.T.hi /tmp/nhc98-1.04/include/IsDigit.T.hi ../Char/IsDigit.T.hi ../PreludeText/IsDigit.T.hi ../PreludeList/IsDigit.T.hi ../Ratio/IsDigit.T.hi when trying to read IsDigit. make[3]: *** [../Numeric/LexDigits.T.hi] Error 1 make[3]: Leaving directory `/tmp/nhc98-1.04/src/prelude/Numeric' make[2]: *** [../Numeric/LexDigits.T.hi] Error 2 make[2]: Leaving directory `/tmp/nhc98-1.04/src/prelude/Char' make[1]: *** [Char.subdir] Error 2 make[1]: Leaving directory `/tmp/nhc98-1.04/src/prelude' make: *** [targets/ix86-CYGWIN_NT-4.0/traceprelude] Error 2 [../Char/IsDigit.t.hi exists, IsDigit.T.hi doesn't; from the tar-file contents, it seems that *.t.hi are generated, whereas *.T.hi come with the sources?] Independent of the actual error (or perhaps not independent?), there is a problem lurking here. You now rely on being able to distinguish between *T* and *t* (tracing and timing), right? Unfortunately, that might not work on cygwin/windows boxes. From the cygwin FAQ: (http://sources.redhat.com/cygwin/faq/faq_4.html#SEC49) Are mixed-case filenames possible with Cygwin? Several Unix programs expect to be able to use to filenames spelled the same way, but with different case. A prime example of this is perl's configuration script, which wants Makefile and makefile. WIN32 can't tell the difference between files with just different case, so the configuration fails. In releases prior to beta 16, mount had a special mixed case option which renamed files in such a way as to allow mixed case filenames. We chose to remove the support when we rewrote the path handling code for beta 16. The standard Windows apps -- explorer.exe, cmd.exe/command.com, etc. -- do not distinguish filenames that differed only in case, resulting in some (very) undesirable behavior. Sergey Okhapkin had maintained a mixed-case patch ('coolview') until about B20.1, but this has not been updated to recent versions of Cygwin. 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 (using cygwin's bash), showing that, while some tools manage to distinguish case, this can't be relied on: touch t.hi T.hi ls t.hi rm T.hi ls touch T.hi t.hi ls T.hi ls | fgrep 't.hi' ls | fgrep 'T.hi' T.hi rm t.hi ls (for more info on this nonsense, see a posting on the cygwin mailing list, http://cygwin.com/ml/cygwin/2000-07/msg00590.html) I'm not sure whether this has anything to do with the second bug, but it is a trap I would like to avoid. I would simply rename one of the suffixes, and try again, but the mapping of features to suffixes seems to be hardwired and distributed all over the place (I couldn't find a variable TRACINGSUFFIX=T), and I don't want to try and search for all uses of t, T, tT, and so on. Unless you can think of any good reason not to, could you please change your suffix scheme back to something that will also work on Windows-inhibited cygwin? Thanks, Claus

2 1

Re: [nhc-bugs] problems installing nhc98-1.04 on cygwin
by C.Reinke 23 May '01

23 May '01

> [../Char/IsDigit.t.hi exists, IsDigit.T.hi doesn't; from the tar-file > contents, it seems that *.t.hi are generated, whereas *.T.hi come > with the sources?] Correction (to avoid confusion): IsDigit.{c,hi,hs,o,p.o,t.o} exist, neither IsDigit.t.hi nor IsDigit.T.hi does. Claus

1 0

Renaming bug?
by Mark Tehver 18 May '01

18 May '01

Hello, I got following error: ==================================== Error when renaming:: Unbound Identifier a0 at 4:44 ... (lots of internal compiler state lines) under NHC 1.02 cygwin (win2k), although I think the program that caused this is correct. The program consists of 2 small files: File Test1.hs: --- module Test1(fn) where import Test2 fn :: Test -> Int fn t@(Test { a0 = a } ) = a0 t + a --- File Test2.hs: --- module Test2(Test(..)) where data Test = Test { a0 :: Int, b0 :: Int } -- I compiled Test2.hs with "nhc98 -c Test2.hs" and then tried to compile Test1.hs and got this error. Best regards, Mark

2 1

trouble with 'make universe' on darwin (mac os x)
by Thomas Hallock 08 May '01

08 May '01

this is what happens when I 'make universe' after a successfull './configure': [localhost:local/nhc98-1.02/src] root# make universe cd syntax; make EXE= SYSTEM='-D__NetBSD__' STATICFLAG='' myinstall cd ugendir; make EXE= sh ../../bin/mycc -s main.o gen.o lex.yy.o y.tab.o id.o tree.o yyerror.o -o ugen /usr/bin/ld: can't use -s with input files containg indirect symbols (output file must contain at least global symbols, for maximum stripping use -x) make[2]: *** [ugen] Error 1 make[1]: *** [ugen] Error 2 make: *** [myinstall] Error 2 I am not too sure about what to do about this. I am doing this using Darwin (Mac OS X). Thanks. __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/

2 1

Re: Nhc-bugs -- confirmation of subscription -- request 451860
by malcolm＠cs.york.ac.uk 03 May '01

03 May '01

1 0