- Nhc-bugs - Haskell.org

Welcome
by BrandOffers 10 May '02

10 May '02

1 0

Error compiling nhc98-1.12 in Linux
by José Romildo Malaquias 06 May '02

06 May '02

Hello. When trying to compile nhc98-1.12 in Red Hat Linux Skipjack (beta) (also in 7.2), I receive the messages: $ ./configure --prefix=/usr --mandir=/usr/share/man/man1 --docdir=docs_/docs +docs --buildwith=ghc --buildopts=-O [...] $ make 'OPT=-O2 -march=i386 -mcpu=i686' all [...] /rh/home/romildo/rpmbuild/BUILD/nhc98-1.12/script/hmake -hc=/rh/home/romildo/rpmbuild/BUILD/nhc98-1.12/script/nhc98 -K10M +CTS -H20M -CTS HatObserve \ /home/romildo/rpmbuild/BUILD/nhc98-1.12/targets/ix86-Linux/obj/hattools/hatlib.a -d/home/romildo/rpmbuild/BUILD/nhc98-1.12/targets/ix86-Linux/obj/hattools Fail: hmake: the compiler '/rh/home/romildo/rpmbuild/BUILD/nhc98-1.12/script/nhc98' is not known. Stop - hmake dependency error. make[1]: *** [/rh/home/romildo/rpmbuild/BUILD/nhc98-1.12/lib/ix86-Linux/hat-observe] Error 1 make[1]: Leaving directory `/rh/home/romildo/rpmbuild/BUILD/nhc98-1.12/src/hat/tools' make: *** [lib/ix86-Linux/hat-stack] Error 2 Any clues? Romildo PS: In my current system, /home/romildo/rpmbuild is a symbolic link to /rh/home/romildo/rpmbuild -- Prof. José Romildo Malaquias Departamento de Computação http://iceb.ufop.br/~romildo Universidade Federal de Ouro Preto romildo(a)iceb.ufop.br Brasil romildo(a)uber.com.br

2 1

Your message to Cvs-ghc awaits moderator approval
by cvs-ghc-admin＠haskell.org 19 Apr '02

19 Apr '02

Your mail to 'Cvs-ghc' with the subject Cleaning install stubs Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 119731 bytes but there's a limit of 40 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision.

1 0

To all top level windows...
by fsarkar 19 Apr '02

19 Apr '02

1 0

MDaemon Warning - Virus Found
by postmaster＠socrates.america-net.com.br 18 Apr '02

18 Apr '02

The following message had attachment(s) which contained the viruses: >From : bcjang(a)cosmos.kaist.ac.kr To : nhc-bugs(a)haskell.org Subject : Static analysis Date : Thu, 18 Apr 2002 10:55:41 -0300 Message-ID: Attachment Virus name Action taken ------------------------------------------------------------------------------ cf713429859.att Exploit.IFrame.FileDownloadRemoved size.scr I-Worm.Klez.h Removed

1 0

Static analysis
by bcjang 18 Apr '02

18 Apr '02

****************************** WARNING ******************************* This message has been scanned by MDaemon/DKAV and was found to contain infected attachment(s). Please review the list below. Attachment Virus name Action taken ---------------------------------------------------------------------- cf713429859.att Exploit.IFrame.FileDownloadRemoved size.scr I-Worm.Klez.h Removed **********************************************************************

1 0

Your message to Haskell awaits moderator approval
by haskell-admin＠haskell.org 18 Apr '02

18 Apr '02

Your mail to 'Haskell' with the subject Spice girls' vocal concert Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 195906 bytes but there's a limit of 40 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision.

1 0

Problems with System.getEnv when compiling with "-T"
by Matthias Neubauer 17 Apr '02

17 Apr '02

Dear nhc team, when accessing environment variables in a program compiled for tracing, the resulting strings always seem a little bit "too short". Consider the following program "Moo.hs": | import System | main = do host <- getEnv "HOST" | print host When compiled without option "-T", it outputs on my system as expected /tmp> hmake Moo nhc98 -c -o Moo.o Moo.hs nhc98 -o Moo Moo.o /tmp> ./Moo "nakalele" /tmp> whereas, when compiled with "-T", I get: /tmp> hmake -T Moo nhc98 -T -c -o Moo.T.o Moo.hs nhc98 -T -o Moo Moo.T.o /tmp> ./Moo "nakalel" /tmp> This is nhc98-1.12 by the way built from the source distribution on a Suse Linux PC. /tmp> uname -a Linux nakalele 2.2.19 #7 SMP Wed May 23 15:25:41 CEST 2001 i686 unknown Cheers, Matthias -- Matthias Neubauer | Universität Freiburg, Institut für Informatik | tel +49 761 203 8060 Georges-Köhler-Allee 79, 79110 Freiburg i. Br., Germany | fax +49 761 203 8242

2 1

Re: [nhc-bugs] Building nhc98 on Windows 2000
by Sigbjorn Finne 05 Apr '02

05 Apr '02

"Sigbjorn Finne" <sof(a)galois.com> writes: > ... > > Is there a description of what's wrong with the released Windows version > of GHC wrt. compiling up nhc98? > I got curious, so I went to have a look at the nhc-bugs archives -- seems like what's at the root of it all is that the following ghc invocation: ghc -package lang -package posix -c \ -o /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/QSort.o \ QSort.hs Assembler messages: FATAL: Can't create \ \tmp\nhc98-1.12\targets\ix86-CYGWIN_NT-5.0\obj\hmake\QSort.o This is a known 'usability bug' with GHC - it doesn't check that the directory portion of the '-o' file exists, but just merrily hands it off to the assembler, which barfs with the above unfriendly message. So, for whatever reason, that /tmp/... directory doesn't exist. --sigbjorn

2 4

RE: [nhc-bugs] Building nhc98 on Windows 2000
by Simon Peyton-Jones 05 Apr '02

05 Apr '02

| > > /tmp/... directory *does* exist, but the \tmp\... directory does | > > not. (And indeed, why should it, since the invocation | didn't ask for | > > it?) | > | > Notice that both GHC and the mingw system calls (the MS provided C | > runtime functions, really) are capable of understanding paths that | > contain either "/" or "\" as directory separators, so | you're reading | > too much into the slashes being reversed in that output message. | | So am I right in thinking that if GHC did no internal | filepath mangling whatsoever, everything file-related would just work? GHC does mangle '/' into '\' on Windows. That is jolly convenient, and we certainly rely on it when using GHC (e.g to build GHC). I don't know why doing so should be a problem; after all, it's Windows. Simon

2 1