RE: ghc 4.00 seg fault on very simple program
Franklin Chen [EMAIL PROTECTED] writes: I am using ghc 4.00 on i386 Linux: Linux dahmer.pscico.cs.cmu.edu 2.0.35 #1-GENERIC Thu Sep 3 09:20:31 EDT 1998 i686 unknown I compiled the following program by ghc Sieve.hs -o Sieve-h and ran it on various inputs. It worked for small n, but seg faulted on larger n: 314 ~/haskell chen@dahmer$ ./Sieve-h 84 /dev/null zsh: 8924 segmentation fault ./Sieve-h 84 /dev/null Thanks for the report - unable to reproduce this behaviour here though (linux (2.0.30 + libc5) and cygwin.) Which ghc-4.00 is this, bin-dist, rpm, compiled from source? --Sigbjorn
ghc 4.00 seg fault on very simple program
T)g(vq4nlh#kLTw3)VBjeKym4+1{PygkT/[G8advE3xwDG)rx]4uf3hQ__Tttxx4D{:q']L"z|D
8]exCk6'A6./E=.5#"j=/2_D"Ji+angC
Sender: [EMAIL PROTECTED]
Precedence: bulk
Resent-Date: Tue, 24 Nov 1998 23:14:52 +
Resent-From: [EMAIL PROTECTED]
Resent-To: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
I am using ghc 4.00 on i386 Linux:
Linux dahmer.pscico.cs.cmu.edu 2.0.35 #1-GENERIC Thu Sep 3 09:20:31 EDT 1998 i686
unknown
I compiled the following program by
ghc Sieve.hs -o Sieve-h
and ran it on various inputs. It worked for small n, but seg faulted
on larger n:
314 ~/haskell chen@dahmer$ ./Sieve-h 84 /dev/null
zsh: 8924 segmentation fault ./Sieve-h 84 /dev/null
module Main (main)
where
import System
primes :: [Int]
primes = sieve [2..]
sieve (p:xs) = p : sieve [ x | x-xs, x `mod` p /= 0 ]
main =
do
args - getArgs
main2 args
main2 :: [String] - IO ()
main2 [arg] = mapM_ print prs
where
num = read arg
prs = take num primes
main2 _ = error "Usage: sieve num\n"
--
Franklin Chen mailto:[EMAIL PROTECTED]
Graduate Student http://www.cs.cmu.edu/~chen/
Computer Science Department Wean Hall 8218
Carnegie Mellon University
RE: Yarrow and ghc-4.00
Simon Ambler [EMAIL PROTECTED] writes: The following compiler error occurred in trying to compile Jan Zwanenburg's proof assistant tool Yarrow with ghc-4.00. ftp://fpt.win.tue.nl/pub/courses/2L560/yarrow/yarrow-src.tar.gz The package says that it works with ghc-2.05 but I thought that I might try it with the latest version. Hugs-1.4 runs it fine and ghc-2.10 compiles it without error. Hope you can figure out the diagnostics! Thanks for a fine report - fixed in ghc-4.01, which should be out shortly. --Sigbjorn
RE: ghc-4.00, s-s-s binary.
Note the Strange behaviour below... Module in question compiles without -O, but not with... Sorry about this. Our Master Plan is to release 4.01 at the end of November, in (I deeply and sincerely hope) a much more robust form than 4.00. (The main thing it won't have is a generational GC.) Can you re-try your bug when this happens? Then we'll polish it during Dec and hope to put out a solid 4.02 at Xmas. It might even have scoped typed variables. Simon
Re: Weekly GHC-4.00 grumbling...
Simon M$ wrote: Here the results from trying to compile today's GHC-4.00: Thanks; all fixed. Huh? The first two bugs have been fixed, but there's still no catchIO in the Prelude, so Exception.lhs still dies a tragic death... (Hmmm, or this could be the traditional Microsoft way of fixing things: Does anyone remember the patch for the patch for the dialup networking? ;-) Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Bcc: Re: Problems with ghc 4.00 and hdirect
Ralf Comtesse [EMAIL PROTECTED] wrote, I have problems using hdirect-current on my system. I have the ghc-4.00 as an rpm-Distribution on a Debian Linux system and used alien to install it. Wenn I try to compile hdirect. 'make boot' and 'make' work fine but 'make lib' gives a segmentation fault: Did you successfully compile any other programs with this installation of ghc-4.00? Which version of the C-library do you have on your system (I built the rpm against glibc-2.0.7)? Manuel
RE: Weekly GHC-4.00 grumbling...
Here the results from trying to compile today's GHC-4.00: Thanks; all fixed. -- Simon Marlow Microsoft Research Ltd., Cambridge, U.K.
RE: Problems with ghc 4.00 and hdirect
Ralf Comtesse [EMAIL PROTECTED] writes: Hello, I have problems using hdirect-current on my system. I have the ghc-4.00 as an rpm-Distribution on a Debian Linux system and used alien to install it. Wenn I try to compile hdirect. 'make boot' and 'make' work fine but 'make lib' gives a segmentation fault: Yup, as mentioned in the announce msg, http://www.dcs.gla.ac.uk/mail-www/haskell/msg01029.html using the hdirect sources with ghc-4.00 is not recommended - use ghc-3.03 instead. --Sigbjorn PS - you may have better luck with 4.00 if you compile the hdirect sources with '-O -dcore-lint', but no guarantees.
Weekly GHC-4.00 grumbling...
Here the results from trying to compile today's GHC-4.00:
* fptools/ghc/rts/StgPrimFloat.c still uses union ieee754_double
(name clash with /usr/include/ieee754.h).
* Compiling fptools/ghc/lib/std/PrelDynamic.lhs fails with:
PrelDynamic.lhs:13: Could not find valid interface file
`Prelude'
Reason: {-# OPTIONS -fno-implicit-prelude #-} comes *after* a
#ifndef __HUGS__-line, but the driver stops looking for options
after such a line. Quick hack: Swap both lines. Doing it right
would probably exceed my Perl-knowledge (-willingness? ;-).
* The compilation of fptools/ghc/lib/std/Exception.lhs dies with:
Exception.lhs:12: Value not in scope: `catchIO'
and there's no catchIO in the whole Prelude.
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
ghc-4.00, s-s-s binary.
Note the Strange behaviour below... Module in question compiles without -O, but not with... Slainte, Alex. _ oconnor.ucc.ie:~/filt4: make OPT=-O ghc-4.00 -c GalileoModules.lhs -H30m -K2M -recomp -fglasgow-exts -cpp -syslib misc -Rgc-stats -dshow-passes -fmax-simplifier-iterations4 -funfolding-use-threshold-0 -optC-fallow-undecidable-instances -fvia-C -O *** Reader: *** Renamer: GalileoModules.lhs:1: Warning: Failed to find (optional) interface decl for `PrelException!catchIO' desired at PrelIOBase.hi:99 GalileoModules.lhs:1: Could not find valid interface file `PrelException' Compilation had errors *** Error code 1 make: Fatal error: Command failed for target `GalileoModules.o' oconnor.ucc.ie:~/filt4: make ghc-4.00 -c GalileoModules.lhs -H30m -K2M -recomp -fglasgow-exts -cpp -syslib misc -Rgc-stats -dshow-passes -fmax-simplifier-iterations4 -funfolding-use-threshold-0 -optC-fallow-undecidable-instances -fvia-C *** Reader: *** Renamer: *** TypeCheck: *** DeSugar: *** Desugar *** Core2Core: *** Simplify *** Tidy Core *** Core2Stg: *** Stg2Stg: *** CodeGen: *** CodeOutput: ghc-4.00: module version changed to 2; reason: usages changed
Can't install H/Direct on Linux with ghc 4.00
I can't get the current H/Direct (0.12) to install on my Linux system with ghc 4.00 (though I used ghc 3.02 to compile ihc). Thanks for any help. - Mark Tullsen Here's what's happening: -- Information about my system: hdirect-0.12 $ uname -a Linux HAGGIS.CS.YALE.EDU 2.0.35 #1 Thu Jul 23 14:01:04 EDT 1998 i686 unknown -- i.e., Red Hat Linux release 5.1 -- What I've Done So Far: cd /usr/local/fptools-3.02; make install (1) -- make ghc-3.02 the compiler -- if I compile with ghc-4.00, ihc core dumps right away -- in step (4). cd /usr/local/hdirect-0.12(2) make boot make cd /usr/local/fptools-4.00; make install (3) -- switch back to ghc-4.00 cd /usr/local/hdirect-0.12(4) make -k lib -- What Happens: -- (granted, some of the following may be bogus thanks to the use of "make -k") hdirect-0.12 $ make -k lib make -C lib boot make -C lib all make[1]: Entering directory `/usr/local/hdirect-0.12/lib' /usr/local/bin/ghc -M -optdep-f -optdep.depend -optdep-o -optdepo-fglasgow-exts -fno-prune-tydecls -recomp Pointer.lhs HDirect.lhs PointerPrim.hs make[1]: Leaving directory `/usr/local/hdirect-0.12/lib' make[1]: Entering directory `/usr/local/hdirect-0.12/lib' /usr/local/bin/ghc -fglasgow-exts -fno-prune-tydecls -recomp -c Pointer.lhs -o Pointer.o -osuf o Pointer.lhs:265: Value not in scope: `foreignObjToAddr' Pointer.lhs:275: Value not in scope: `foreignObjToAddr' Pointer.lhs:308: Value not in scope: `foreignObjToAddr' Compilation had errors make[1]: *** [Pointer.o] Error 1 /usr/local/bin/ghc -fglasgow-exts -fno-prune-tydecls -recomp -c AutoPrim.hs -o AutoPrim.o -osuf o AutoPrim.hs:8: Could not find valid interface file `Com' AutoPrim.hs:8: Module `Com' does not export `checkHR' AutoPrim.hs:8: Module `Com' does not export `marshalliptr' AutoPrim.hs:8: Module `Com' does not export `IUnknown' AutoPrim.hs:8: Module `Com' does not export `mkIID' AutoPrim.hs:8: Module `Com' does not export `IID' AutoPrim.hs:9: Could not find valid interface file `HDirect' AutoPrim.hs:9: Module `HDirect' does not export `Ptr' AutoPrim.hs:9: Module `HDirect' does not export `sizeofAddr' AutoPrim.hs:9: Module `HDirect' does not export `allocOutPtr' AutoPrim.hs:9: Module `HDirect' does not export `marshallBool' AutoPrim.hs:9: Module `HDirect' does not export `marshallptr' AutoPrim.hs:9: Module `HDirect' does not export `readptr' AutoPrim.hs:9: Module `HDirect' does not export `unmarshallref' AutoPrim.hs:9: Module `HDirect' does not export `trivialFree' AutoPrim.hs:9: Module `HDirect' does not export `doThenFree' AutoPrim.hs:9: Module `HDirect' does not export `sizeofInt32' AutoPrim.hs:9: Module `HDirect' does not export `readInt32' AutoPrim.hs:9: Module `HDirect' does not export `unmarshallString' AutoPrim.hs:9: Module `HDirect' does not export `freeString' AutoPrim.hs:9: Module `HDirect' does not export `sizeofInt16' AutoPrim.hs:9: Module `HDirect' does not export `readInt16' AutoPrim.hs:9: Module `HDirect' does not export `sizeofFloat' AutoPrim.hs:9: Module `HDirect' does not export `readFloat' AutoPrim.hs:9: Module `HDirect' does not export `sizeofDouble' AutoPrim.hs:9: Module `HDirect' does not export `readDouble' AutoPrim.hs:9: Module `HDirect' does not export `readBool' AutoPrim.hs:9: Module `HDirect' does not export `sizeofChar' AutoPrim.hs:9: Module `HDirect' does not export `readChar' AutoPrim.hs:9: Module `HDirect' does not export `unmarshallBool' Compilation had errors make[1]: *** [AutoPrim.o] Error 1 /usr/local/bin/ghc -fglasgow-exts -fno-prune-tydecls -recomp -c ComPrim.hs -o ComPrim.o -osuf o ComPrim.hs:6: Could not find valid interface file `HDirect' ComPrim.hs:10: Could not find valid interface file `Pointer' Compilation had errors make[1]: *** [ComPrim.o] Error 1 /usr/local/bin/ghc -monly-3-regs -fglasgow-exts -fno-prune-tydecls -recomp -c WideString.hs -o WideString.o -osuf o WideString.hs:7: Could not find valid interface file `Pointer' WideString.hs:8: Could not find valid interface file `HDirect' WideString.hs:11: Module `Foreign' does not export `foreignObjToAddr' Compilation had errors make[1]: *** [WideString.o] Error 1 cc -DCOM -c PointerSrc.c -o PointerSrcCom.o In file included from PointerSrc.c:40: comPrim.h:13: parse error before `IID' comPrim.h:13: warning: data definition has no type or storage class comPrim.h:28: parse error before `OLECHAR' comPrim.h:28: warning: data definition has no type or storage class comPrim.h:29: parse error before `*' comPrim.h:29: warning: data definition has no type or storage class comPrim.h:30: parse error before `*' comPrim.h:30: warning: data definition has no type or storage class comPrim.h:32: parse error before `*' comPrim.h:32: warning: data definition has no type or sto
Problems with ghc 4.00 and hdirect
-BEGIN PGP SIGNED MESSAGE-
Hello,
I have problems using hdirect-current on my system. I have the
ghc-4.00 as an rpm-Distribution on a Debian Linux system and used alien
to install it.
Wenn I try to compile hdirect. 'make boot' and 'make' work fine but
'make lib' gives a segmentation fault:
Here is the output:
rcc:~/tmp/hdirect-0.12# make lib
make -C lib boot make -C lib all
make[1]: Entering directory `/home/rcc/tmp/hdirect-0.12/lib'
../src/ihc -fno-qualified-names -fno-imports
- -fout-pointers-are-not-refs -fno-export-lists -c ComPrim.idl -o
ComPrim.hs
make[1]: *** [ComPrim.hs] Segmentation fault
make[1]: *** Deleting file `ComPrim.hs'
make[1]: Leaving directory `/home/rcc/tmp/hdirect-0.12/lib'
make: *** [lib] Error 2
===
and that are the last bits of a 'strace'
==
open("ComPrim.hs", O_WRONLY|O_NOCTTY) = -1 ENOENT (No such file or
directory)
lstat("ComPrim.hs", 0xb24c) = -1 ENOENT (No such file or
directory)
open("ComPrim.hs", O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY, 0666) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open("ComPrim.hs", O_WRONLY|O_TRUNC|O_NOCTTY) = 4
close(4)= 0
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
brk(0x82dd000) = 0x82dd000
- --- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
==
Has anybody got an idea?
Regards
Ralf
-
Ralf Comtessee-Mail: [EMAIL PROTECTED]
Gipsstrasse 15 Tel: +49-30-28599230
10119 Berlin Fax: +49-30-28599231
Member of the Cetus Team. For OO links visit: http://www.cetus-links.org
-
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv
iQB1AwUBNlM78Q+XSzNOWOS5AQHDdAMAzNufAKs0V6PWsr6yNsCJz11fDx56saUg
gH7YCxICaECLLeNa5XQ6jBeMCOqSy977PB+O/hhUUwKrQBJinMOrNo2fYqmhrE/K
kLupvfsMGfPKqapuDowi7aAseFkTsaC0
=NC2P
-END PGP SIGNATURE-
ghc-4.00
Still can't build 4.00 from source (see bug report, elselist), and it's also not yet on the ftp site in binary form. *whinge!* Slainte, Alex.
problem with ghc-4.00 freebsd binary
seems to be generating incomplete C code:
~~~
ghc-4.00 -c -cpp -syslib misc -fglasgow-exts -H27M
-DAFMPATH=\\\"/usr/local/tex/Adobe\\\" -DRGBPATH=\\\"/usr/lib/X11\\\"
CommandLine.hs -o CommandLine.o
/usr/libexec/ld.so: warning: /usr/lib/libc.so.3.0: minor version 0 older
than expected 1, using it anyway
ghc-4.00: module version changed to 1; reason: no old .hi file
/tmp/ghc13164.hc:4106: `__ap_31_upd_info' undeclared (first use in this
function)
/tmp/ghc13164.hc:4106: (Each undeclared identifier is reported only once
/tmp/ghc13164.hc:4106: for each function it appears in.)
gmake: *** [CommandLine.o] Error 1
~~~
from the attached source.
-Peter
module CommandLine (parse_cmds) where
import System
defaultArgs :: Args
defaultArgs = MkArgs "Times-Roman" 10 "black" "Times-Roman" 10 "black" "white"
"black" "Times-Roman" 10 "black" "white" "black" "black" 500 500 30 100 200 "rgb.txt"
False False False False True False False False False
usage :: IO ()
usage = putStr "Usage: prog [-titleFont String] [-titleScale Int] [-titleColor
String] [-ntFont String] [-ntScale Int] [-ntColor String] [-ntBg String] [-ntBoxColor
String] [-tFont String] [-tScale Int] [-tColor String] [-tBg String] [-tBoxColor
String] [-lineColor String] [-borderDistX Int] [-borderDistY Int] [-lineWidth Int]
[-fatLineWidth Int] [-arrowSize Int] [-rgbFileName String] [-happy] [-yacc]
[(+|-)simplify] [(+|-)unfold] [(+|-)ps] [(+|-)fig] [(+|-)ebnf] [-help] [-verbose]\n"
data Args = MkArgs String Int String String Int String String String String Int
String String String String Int Int Int Int Int String Bool Bool Bool Bool Bool Bool
Bool Bool Bool deriving ()
type ProgType = String - Int - String - String - Int - String - String - String
- String - Int - String - String - String - String - Int - Int - Int - Int
- Int - String - Bool - Bool - Bool - Bool - Bool - Bool - Bool - Bool -
Bool - [String] - IO ()
parse_args :: ProgType - Args - [String] - IO ()
parse_args prog (MkArgs x1 x2 x3 x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 x16 x17 x18
x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29) ("-titleFont":rest)
= readstring (\str - parse_args prog (MkArgs str x2 x3 x4 x5 x6 x7 x8 x9 x10 x11
x12 x13 x14 x15 x16 x17 x18 x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29)) rest
parse_args prog (MkArgs x1 x2 x3 x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 x16 x17 x18
x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29) ("-titleScale":rest)
= readval reads (\val - parse_args prog (MkArgs x1 val x3 x4 x5 x6 x7 x8 x9 x10
x11 x12 x13 x14 x15 x16 x17 x18 x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29)) rest
parse_args prog (MkArgs x1 x2 x3 x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 x16 x17 x18
x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29) ("-titleColor":rest)
= readstring (\str - parse_args prog (MkArgs x1 x2 str x4 x5 x6 x7 x8 x9 x10 x11
x12 x13 x14 x15 x16 x17 x18 x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29)) rest
parse_args prog (MkArgs x1 x2 x3 x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 x16 x17 x18
x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29) ("-ntFont":rest)
= readstring (\str - parse_args prog (MkArgs x1 x2 x3 str x5 x6 x7 x8 x9 x10 x11
x12 x13 x14 x15 x16 x17 x18 x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29)) rest
parse_args prog (MkArgs x1 x2 x3 x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 x16 x17 x18
x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29) ("-ntScale":rest)
= readval reads (\val - parse_args prog (MkArgs x1 x2 x3 x4 val x6 x7 x8 x9 x10
x11 x12 x13 x14 x15 x16 x17 x18 x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29)) rest
parse_args prog (MkArgs x1 x2 x3 x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 x16 x17 x18
x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29) ("-ntColor":rest)
= readstring (\str - parse_args prog (MkArgs x1 x2 x3 x4 x5 str x7 x8 x9 x10 x11
x12 x13 x14 x15 x16 x17 x18 x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29)) rest
parse_args prog (MkArgs x1 x2 x3 x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 x16 x17 x18
x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29) ("-ntBg":rest)
= readstring (\str - parse_args prog (MkArgs x1 x2 x3 x4 x5 x6 str x8 x9 x10 x11
x12 x13 x14 x15 x16 x17 x18 x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29)) rest
parse_args prog (MkArgs x1 x2 x3 x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 x16 x17 x18
x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29) ("-ntBoxColor":rest)
= readstring (\str - parse_args prog (MkArgs x1 x2 x3 x4 x5 x6 x7 str x9 x10 x11
x12 x13 x14 x15 x16 x17 x18 x19 x20 x21 x22 x23 x24 x25 x26 x27 x28 x29)) rest
parse_args prog (MkArgs x1 x2 x3 x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 x16 x17 x18
x19 x20 x21 x22 x23 x24 x25 x26
GHC-4.00 source build
Some minor quirks with today's ghc-4.00:
* fptools/ghc/rts/StgPrimFloat.c did not compile because of the redefiniton of
union ieee754_double, which is already defined in /usr/include/ieee754.h on
my Linux (libc5) box. Fix: rename ieee754_double to my_ieee754_double. This
works, but autoconf should better check for this.
* Word.lhs needs a little bit more heap for compilation:
diff -r fptools.orig/ghc/lib/exts/Makefile fptools/ghc/lib/exts/Makefile
43c43
Word_HC_OPTS += -H12m
---
Word_HC_OPTS += -H16m
* Remove some imports in PosixIO (PrelHandle does not export these):
diff -r fptools.orig/ghc/lib/posix/PosixIO.lhs
fptools/ghc/lib/posix/PosixIO.lhs
34c34
import PrelHandle (readHandle, writeHandle, newHandle, getBMode__,
getHandleFd )
---
import PrelHandle (newHandle, getBMode__, getHandleFd )
* fptools/distrib is missing. My quick hack: Use the one from 3.03.
* The stubs generated for the FFI include rtsdefs.h instead of Rts.h.
* The C compiler complains when using foreign exports:
/tmp/ghc17785.hc:242: macro `STK_CHK' used with too many (7) args
* GHC dies during the compilation of:
module Foo where
import GlaExts(Addr)
foreign export _ccall dynamic myBaz :: (Int - IO Char) - IO Addr
with the message:
panic! (the `impossible' happened):
applyTypeToArgs {-_ccall-}_ccall_ createAdjustor {dDT
0
dDU
(_litlit_ "dEc"
PrelAddr.Addr{-32,W-})}
Please report it as a compiler bug to [EMAIL PROTECTED]
* Bootstrapping does not work at all: The compilation of
fptools/ghc/compiler/utils/FastString.lhs
aborts with:
FastString.lhs:64: Module `PrelHandle' does not export `readHandle'
Alas, grepping through the whole fptools directory reveals no definition of
readHandle...
Apart from that, everything was OK... :-}
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Re: ghc-4.00 cvs source build question
This morning I got the cvs source tree from CVSROOT="[EMAIL PROTECTED]:/cvs" [..] Did you put Version 3.03 back in the repository? Or is it just the wrong name? [to the list because I had the same problem] The head of the tree is still 3.03; if you want 4 you have to do cvs co -r new-rts fpconfig cd fptools cvs co -r new-rts ghc HTH. --KW 8-) -- : Keith Wansbrough, MSc, BSc(Hons) (Auckland) : : PhD Student, Computer Laboratory, University of Cambridge, England. : : (and recently of the University of Glasgow, Scotland. [] ) : : Native of Antipodean Auckland, New Zealand: 174d47' E, 36d55' S.: : http://www.cl.cam.ac.uk/users/kw217/ mailto:[EMAIL PROTECTED] : :-:
ghc-4.00 cvs source build question
Hello, This morning I got the cvs source tree from CVSROOT="[EMAIL PROTECTED]:/cvs" The build created the files lrwxrwxrwx 1 laitenbe pardc 8 Nov 12 07:09 ghc - ghc-3.03* -rwxr-xr-x 1 laitenbe pardc 103189 Nov 12 07:09 ghc-3.03* -rwxr-xr-x 1 laitenbe pardc 36772 Nov 12 07:09 hp2ps* -rwxr-xr-x 1 laitenbe pardc 2946 Nov 12 07:09 hstags* -rwxr-xr-x 1 laitenbe pardc 19993 Nov 12 07:09 mkdependHS* -rwxr-xr-x 1 laitenbe pardc 2558 Nov 12 07:09 stat2resid* in the bin directory. Did you put Version 3.03 back in the repository? Or is it just the wrong name? Best Wishes, Jan ___ '---|-- | __, _ _ EMail: [EMAIL PROTECTED] | / | / |/ | WWWeb: http://www.uni-passau.de/~laitenbe/ |/\_/|_/ | |_/ /| Laitenberger --(-|-- \|
GHC 4.00 symbol ... is multiply defined
Hi! The final ghc call to combine the object files of our project /public/languages/ghc-4.00/bin/ghc -o P -H30M Avl.o Codegen.o produces ld: fatal: symbol `DoubleNaN' is multiply defined: (file /public/languages/ghc-4.00/lib/ghc-4.00/libHS_cbits.a(floatExtreme.o) and file /public/languages/ghc-4.00/lib/ghc-4.00/libHSrts.a(StgPrimFloat.o)); messages. (also for symbols isFloatInfinite, isFloatDenormalized, isFloatNegativeZero, isDoubleInfinite, isDoubleDenormalized, isDoubleNegativeZero, isFloatNaN) What can I do to avoid this? Many thanks in advance, Jan ___ '---|-- | __, _ _ EMail: [EMAIL PROTECTED] | / | / |/ | WWWeb: http://www.uni-passau.de/~laitenbe/ |/\_/|_/ | |_/ /| Laitenberger --(-|-- \|
RE: GHC 4.00 symbol ... is multiply defined
Jan Laitenberger [EMAIL PROTECTED] writes:
Hi!
The final ghc call to combine the object files of our project
/public/languages/ghc-4.00/bin/ghc -o P -H30M Avl.o Codegen.o
produces
ld: fatal: symbol `DoubleNaN' is multiply defined:
(file
/public/languages/ghc-4.00/lib/ghc-4.00/libHS_cbits.a(floatExtreme.o)
and file
/public/languages/ghc-4.00/lib/ghc-4.00/libHSrts.a(StgPrimFloat.o));
messages. (also for symbols isFloatInfinite, isFloatDenormalized,
isFloatNegativeZero, isDoubleInfinite, isDoubleDenormalized,
isDoubleNegativeZero, isFloatNaN)
What can I do to avoid this?
Do a 'cvs update' - this was fixed sometime yesterday afternoon.
(i.e., ghc/lib/std/cbits/floatExtreme.{c,h} doesn't exist any longer.)
--Sigbjorn
RE: Downloading binary ghc 4.00
On Wed, 11 Nov 1998, Simon Marlow wrote: The file ftp://ftp.dcs.gla.ac.uk/pub/haskell/glasgow/4.00/ghc-4.00-sparc-sun-solaris2.tar.gz is not readable (except for the owner). I assume this is not intended. Fixed, sorry about that. I cannot find this file. There are only Linux and FreeBSD versions in this directory. Tony Antony Bowers, Department of Computer Science, University of Bristol, UK. http://www.cs.bris.ac.uk/~bowers/
Re: ghc-4.00 build problems.
I whinged about: [stuff] Other people seem to have got further than I did in sun-sparc builds -- is there a workaround that I could be using, pending an actual fix? [ Or enough ftp space for the binary version. ;-) ] Slan, Alex.
ghc-4.00 build problems.
Hi all. Some build gotchas which I haven't seen reported (which
makes me wonder what stupid thing I did that others have not).
Setup is Solaris 2.5, ghc-3.02.
Firstly: gnumake all fails in build gmp, thusly:
gnumake -C gmp MAKEFLAGS=
cd mpn; gnumake "CC=../../ghc/driver/ghc " "CFLAGS=-O" "XCFLAGS=" libmpn.a
gnumake[3]: Entering directory
`/export/home/ferguson/ghc-4.00/build/ghc/rts/gmp/mpn'
../../ghc/driver/ghc -c -I. -I.. -I. -I./.. -O mp_bases.c
gnumake[3]: ../../ghc/driver/ghc: Command not found
Looks like it needs to be using ../../../../ghc/driver/ghc at this
point, so far as I can tell.
Hacking around this, I then get some assembler problems:
../../../../ghc/driver/ghc -c tmp-udiv_fp.s -o udiv_fp.o
/usr/ccs/bin/as: "tmp-udiv_fp.s", line 1: error: invalid character (0x7b)
/usr/ccs/bin/as: "tmp-udiv_fp.s", line 1: error: invalid character (0x4c)
/usr/ccs/bin/as: "tmp-udiv_fp.s", line 1: error: unknown opcode "LINE"
/usr/ccs/bin/as: "tmp-udiv_fp.s", line 1: error: invalid character (0x7d)
/usr/ccs/bin/as: "tmp-udiv_fp.s", line 1: error: statement syntax
/usr/ccs/bin/as: "tmp-udiv_fp.s", line 38: error: statement syntax
/usr/ccs/bin/as: "tmp-udiv_fp.s", line 39: error: unknown opcode "C_SYMBOL_NAME"
/usr/ccs/bin/as: "tmp-udiv_fp.s", line 39: error: statement syntax
Offending lines look like:
{-# LINE 1 "udiv_fp.S" -}
(Unrecognised comment, it seems.) and:
.global C_SYMBOL_NAME(__udiv_qrnnd)
C_SYMBOL_NAME(__udiv_qrnnd):
(Which is bad label syntax.)
Then I get 83 million similiar errors in tmp-add_n.s, in the same place.
At this point I lost the will to live, much less debug assembler by
hand. Satnam Singh suggests the problem is a missing include of a
bunch of as-macros which make the above make sense, if that helps.
Slan libh,
Alex.
Re: GHC 4.00 Funny global thing?
Jan Laitenberger [EMAIL PROTECTED] writes: Hi, ghc -c -fvia-C -O2 -H45M Resolve.hs shows NOTE: Simplifier still going after 4 iterations; baling out. ghc: module version changed to 1; reason: no old .hi file Funny global thing?: cmUf_btm: Funny global thing?: cmUg_btm: This means you've got a pretty complex bit of code that needed a bitmap with more than 32 entries to describe a stack frame. Cool :-) Resolve.hi and Resolve.o are generated. Can the "Funny global thing?" message be ignored? (It does not crash the compiler.) Yep, the warning can be ignored. Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
Re: Further newbie compilation problems with GHC 4.00
Andrew Cheadle [EMAIL PROTECTED] writes: [compilation output] ==fptools== make all -r; in /a/hex/export32/bitbucket/amc4/development/fptools/ghc/lib/std rm -f PrelBase.o ; if [ ! -d PrelBase ]; then mkdir PrelBase; else find PrelBase -name '*.o' -print | xargs rm -f __rm_food ; fi ; ../../../ghc/driver/ghc -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O -split-objs -odir PrelBase -H10m -c PrelBase.lhs -o PrelBase.o -osuf o PrelBase.lhs:18: Could not find valid interface file `PrelErr' PrelBase.lhs:18: Module `PrelErr' does not export `error' PrelBase.lhs:19: Could not find valid interface file `PrelGHC' This is on a fairly recent Linux installation w/ glibc, right? I had the same problem when I tried to compile 4.00 on one of the RedHat 5 boxes at Glasgow, but didn't get a chance to look into it. Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
Re: GHC-4.00 Dynamic Heap Sizing
Tim Pollitt [EMAIL PROTECTED] writes: This feature is great, especially for programs which don't have flat heap usage needs. Finding a good default sizing policy, and a simple set of controlling options, may be a little tricky. From the GC stats I get the impression that not all live structure is accounted as heap. If some objects (eg. arrays) incurring GC costs are ignored by resizing decisions, then it's possible for the collector to recover nearly all of a tiny heap, but spend nearly all CPU on tracing through an enormous array each time it collects the tiny heap. That's true. Large objects (larger than 4k) aren't counted as live heap. It's not clear whether this is the right or wrong thing to do: the large objects aren't copied during GC, but they may be traced (eg. a large array of pointers). Furthermore, the live data strictly speaking should include the stack for each running thread (it doesn't currently). It's unlikely that the GC stats could be skewed by this: you'd need a huge array with all elements pointing to the same object. I think rts.ps mentioned the possibility of using page fault stats to automatically tune sizing. In some cases the user may already have a good estimate of available real memory, and find it convenient to specify a size (between the limits) which should be exceeded only when really necessary. I'm not sure whether you'd want to set this by hand or have the RTS deal with it automatically, although I suspect the latter will give better results. The amount of free real memory in the system will likely fluctuate quite a bit, possibly during the run of the program itself. The downside of letting the RTS decide how much memory to use would be that it would start paging before it detected the fact and reduced memory consumption. Better OS support would help. Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
RE: instance Show (a-b) (was Re: GHC-4.00 assembler crash)
Felix Schroeter [EMAIL PROTECTED] writes: To quote from somewhere deep within the Prelude: instance Show (a - b) where showsPrec _ _ = showString "function" [meta-comment: could we just do away with this one? Beyond giving rise to semi-entertaining bugs, it's of precious little practical use..] I think, it IS of practical use for hugs users, as it prints function as a response of a function valued expression instead of an error message that it can't find an instance of Show for the type of the entered expression. That's a Hugs user interface issue, and can be solved without polluting the Haskell Prelude, i.e., no need to burden the rest of us with it ;-) begin 600 MachRegs.diff Why not in clear text? :-) because Outlook scares me no end :-) [... uuencode deleted ...] Regards, Felix. PS: The Message-Id in your mail is a bit strange. Usually, it should be [EMAIL PROTECTED]. Maybe so, but it's within the bounds of what constitutes a legal addr-spec as per RFC 822. --Sigbjorn
instance Show (a-b) (was Re: GHC-4.00 assembler crash)
Hello! On Tue, Oct 20, 1998 at 12:36:44AM -0700, Sigbjorn Finne (Intl Vendor) wrote: [...] To quote from somewhere deep within the Prelude: instance Show (a - b) where showsPrec _ _ = showString "function" [meta-comment: could we just do away with this one? Beyond giving rise to semi-entertaining bugs, it's of precious little practical use..] I think, it IS of practical use for hugs users, as it prints function as a response of a function valued expression instead of an error message that it can't find an instance of Show for the type of the entered expression. Thanks for the report; fixed (one line patch attached.) --Sigbjorn begin 600 MachRegs.diff Why not in clear text? :-) [... uuencode deleted ...] Regards, Felix. PS: The Message-Id in your mail is a bit strange. Usually, it should be [EMAIL PROTECTED].
RE: Further newbie compilation problems with GHC 4.00
[g-h-b listeners - sorry for slacking off on replying to bug msgs over the last couple of days. Things should be back to a more normal state soon..] Andrew Cheadle [EMAIL PROTECTED] writes: ... ../../../ghc/driver/ghc -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O -split-objs -odir PrelBase -H10m -c PrelBase.lhs -o PrelBase.o -osuf o PrelBase.lhs:18: Could not find valid interface file `PrelErr' PrelBase.lhs:18: Module `PrelErr' does not export `error' PrelBase.lhs:19: Could not find valid interface file `PrelGHC' Odd; make sure that you've got PrelErr.hi-boot (and PrelGHC.hi-boot) in ghc/lib/std (don't know why they shouldn't be there, but worth checking.) If that doesn't show up anything unexpected, do cd ghc/lib/std make EXTRA_HC_OPTS='-dshow-rn-trace -optC-dshow-rn-imports' and let us know what this produced on stderr. Also, what does 'uname -a' 'grep C_LIB_VERSION /usr/include/*.h' report? --Sigbjorn
RE: GHC-4.00 unimplemented check
Jan Laitenberger [EMAIL PROTECTED] writes: We use a small Avl module in our compiler project. GHC 4.00 crashes with the error message "unimplemented check" when compiling with ghc -c -O -H45M Avl.hs - but ghc -c -H45M Avl.hsand ghc -c -O2 -H45M Avl.hs will compile without error messages. Why? There's a couple of heap checks that are unimplemented by the native code generator, hence the crash. For now, turn off the use of the native code generator and compile with -fvia-C instead. (which is what -O2 does.) --Sigbjorn
GHC-4.00 assembler crash
Hi, Compiling our interpreter module causes the assembler to crash ghc -c -H45M Inter.hs returns: /usr/ccs/bin/as: "/tmp/ghc22153.s", line 572: error: statement syntax /usr/ccs/bin/as: "/tmp/ghc22153.s", line 572: error: statement syntax /usr/ccs/bin/as: "/tmp/ghc22153.s", line 590: error: statement syntax /usr/ccs/bin/as: "/tmp/ghc22153.s", line 590: error: statement syntax These lines look like: (I used -S to get the assembler file) .word 0rfunction Is this a valid assembler syntax?? If I delete "rfunction" the assembler accepts the program. But is it still correct then? Best Wishes, Jan ___ '---|-- | __, _ _ EMail: [EMAIL PROTECTED] | / | / |/ | WWWeb: http://www.uni-passau.de/~laitenbe/ |/\_/|_/ | |_/ /| Laitenberger --(-|-- \|
RE: GHC-4.00 assembler crash
Jan Laitenberger [mailto:[EMAIL PROTECTED]] writes:
Hi,
Compiling our interpreter module causes the assembler to crash
ghc -c -H45M Inter.hs
returns:
/usr/ccs/bin/as: "/tmp/ghc22153.s", line 572: error:
statement syntax
/usr/ccs/bin/as: "/tmp/ghc22153.s", line 572: error:
statement syntax
/usr/ccs/bin/as: "/tmp/ghc22153.s", line 590: error:
statement syntax
/usr/ccs/bin/as: "/tmp/ghc22153.s", line 590: error:
statement syntax
These lines look like: (I used -S to get the assembler file)
.word 0rfunction
Is this a valid assembler syntax?? If I delete "rfunction"
the assembler accepts the program. But is it still correct then?
To quote from somewhere deep within the Prelude:
instance Show (a - b) where
showsPrec _ _ = showString "function"
[meta-comment: could we just do away with this one? Beyond giving
rise to semi-entertaining bugs, it's of precious little practical use..]
Thanks for the report; fixed (one line patch attached.)
--Sigbjorn
begin 600 MachRegs.diff
M*BHJ(-O;7!I;5R+VYA=EV94=E;B]-86-H4F5GRYL:',),3DY."\P.2\R
M.2`Q-3HP,3HS.`DQ+C$V+C(N-@T*+2TM(-O;7!I;5R+VYA=EV94=E;B]-
M86-H4F5GRYL:',),3DY."\Q,"\R,"`P-SHS,3HR,`T**BHJ*BHJ*BHJ*BHJ
M*BHJ#0HJ*BH@.3,L.3D@*BHJ*@T*("`)($E7T%20TA?86QP:$HRUPF5P
M96YD(YO=AI;FM?0T*("`)+$E7T%20TA?:3,X-B@@)S`G(#H@)V0G(#H-
M"B`@"2Q)1E]!4D-(7W-P87)C*"P)R`Z("=R)R`Z+"DI*0T*(2`)VAO=R`H
MF%T:6]N86P@BDI#0H@(%QE;F1[8V]D97T-"B`@#0H@("4@+2`M("T@+2`M
M("T@+2`M("T@+2`M("T@+2`M("T@+2`M("T@+2`M("T@+2`M("T@+2`M("T@
M+2`M("T@+2`M("T@+0T*+2TM(#DS+#DY("TM+2T-"B`@"2!)1E]!4D-(7V%L
MAA*'LM')E5N9"!N;W1H:6YG+7T-"B`@"2Q)1E]!4D-(7VDS.#8H("P
M)R`Z("=D)R`Z#0H@(`DL249?05)#2%]S%R8R@G,"@.B`GB@.BPI*2D-
M"B$@"7-H;W=31]C("AR871I;VYA;"!R*2D-"B`@75N9'MC;V1E?0T*("`-
M"B`@)2`M("T@+2`M("T@+2`M("T@+2`M("T@+2`M("T@+2`M("T@+2`M("T@
=+2`M("T@+2`M("T@+2`M("T@+2`M("T@+2`M#0H=
`
end
GHC-4.00 gmake boot problem
Hi, gmake boot fails. Here are the last lines of the output: (I left out some of the .hs files on the command line of ghc) ==fptools== gmake boot --no-print-directory -r; in /home/cl/laitenbe/tmp/fptools/ghc/compiler ghc -M -optdep-f -optdep.depend -optdep-o -optdepo-cpp -fglasgow-exts\ -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils:basicTypes:types:\ hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:\ stranal:stgSyn:simplStg:codeGen:absCSyn:main:reader:profiling:parser:\ nativeGen -recomp parser/U_binding.hs parser/U_constr.hs\ parser/U_either.hs parser/U_entidt.hs [...] No file `Addr.hi', `Addr.lhs', `Addr.hs' (reqd from file `utils/DirUtils.lhs') among import directories: .:utils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:\ coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:\ absCSyn:main:reader:profiling:parser:nativeGen gmake[2]: *** [depend] Error 1 What can I do to solve this problem? Which Addr.* file is required? The one from ghc-4.00 or from ghc-2.10 (which I use for the compilation) I tried to add the ../lib/exts to the -i switch in ghc/compiler/Makefile. There is Addr.lhs. - This causes "gmake all" to fail with these error messages ghc -cpp ... -c ../lib/exts/GlaExts.lhs -o ../lib/exts/GlaExts.o -osuf o ../lib/exts/GlaExts.lhs:62: Could not find valid interface file `PrelGHC' ../lib/exts/GlaExts.lhs:64: Could not find valid interface file `PrelAddr' [...] I also tried to import from /public/languages/ghc-2.10/lib/ghc-2.10/imports. Then the error messages after "gmake all" look like these: ../lib/exts/GlaExts.lhs:62: Could not find valid interface file `PrelGHC' ../lib/exts/GlaExts.lhs:64: Could not find valid interface file `PrelAddr' ../lib/exts/GlaExts.lhs:64: Module PrelAddr does not export `Addr'(..) [...] Thanks in advance, Jan ___ '---|-- | __, _ _ EMail: [EMAIL PROTECTED] | / | / |/ | WWWeb: http://www.uni-passau.de/~laitenbe/ |/\_/|_/ | |_/ /| Laitenberger --(-|-- \|
undocumented feature in GHC-4.00?
When attempting to reconstruct the syntax for existential quantification, I tried: newtype Groo a = Groo (Either a b) To my surprise, using ghc-4.00, this worked - without even using `-fglasgow-exts'. (it doesn't work, with or without `-fglasgow-exts' under 3.02) Then I read the release notes ;-) These told me about using `forall' on `data' declarations. But the above works, and yields the type I was expecting, i.e. the .hi file sez: newtype Groo $r3r = Groo (_forall_ [$r3u] = PrelEither.Either $r3r $r3u) ; Is this a feature or a bug? --Jeff
GHC 4.00 bugs
Here the latest bug news on GHC 4.00 from Munich... :-)
My installation went the usual path: First compile quick-and-dirty GHC-4.00
with GHC-3.03, then test the whole thing by bootstrapping.
Platform: Linux (libc5)
* Some "classic" warnings in ghc/rts:
/usr/include/stdlib.h:149: warning: no previous prototype for `strtold'
Hmm, perhaps I should better not mention my fix, otherwise Simon
gets pale again... (see Sep 1st)
* Some warnings about (almost) nested comments in gum/{HLComms,ParInit}.c:
gum/HLComms.c:125: warning: `/*' within comment
Perhaps use #ifdef 0...#endif instead of /*...*/
* Compiling ghc/compiler/rename/ParseIface.hs with GHC 4.00 itself
needs 40MB instead of the 30MB given in ghc/compiler/Makefile.
Hmmm, 30MB was enough when compiling 4.00 with 3.03. Even stranger:
What about the promised self-adjusting heap in the new RTS? I hoped
no -H/-K has to be used with the shiny new RTS... :-(
* In the boostrapping phase (4.00 with 4.00), there are some strange
warnings from gcc, but only on some files, e.g.
basicTypes/Var.lhs
types/Type.lhs
typecheck/TcEnv.lhs
typecheck/TcHsSyn.lhs
typecheck/Inst.lhs
gcc complained:
/home/inst/glasgow/linux/bin/ghc -cpp -fglasgow-exts -Rghc-timing -I.
-IcodeGen -InativeGen -Iparser
-iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:reader:profiling:parser:nativeGen
-recomp -H10m -c typecheck/TcEnv.lhs -o typecheck/TcEnv.o -osuf o
ghc: 271383260 bytes, 95 GCs, 2432854/3116888 avg/max bytes residency (5
samples), 0.03 INIT (0.00 elapsed), 13.31 MUT (15.00 elapsed), 4.39 GC (4.72 elapsed)
:ghc
ghc: module version changed to 1; reason: no old .hi file
/tmp/ghc6681.hc:3700: warning: `c6BS_closure' was declared `extern' and later
`static'
/tmp/ghc6681.hc:4010: warning: `c6C2_closure' was declared `extern' and later
`static'
/tmp/ghc6681.hc:4163: warning: `c6C7_closure' was declared `extern' and later
`static'
* foreign is a little bit buggy:
module Test where
foreign export _ccall "bar" myBar :: IO ()
myBar = putStrLn "Hi!"
leads to
panne:~/tst ghc -c -fglasgow-exts Test.hs
ghc: module version changed to 1; reason: no old .hi file
/tmp/ghc7265.hc:118: macro `STK_CHK' used with too many (7) args
Test_stub.h contains another surprise:
#include "rtsdefs.h"
extern void bar (void* _a0) ;
Where is the void* coming from? I expected: extern void bar(void);
Cheers,
Sven
P.S.: I'm slowly getting old, this is *not* the first bug report on
4.00... :'-(
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
[Fwd: GHC 4.00 bugs]
[ I've only replied Sigbjorn, so here's it again... ]
Sigbjorn Finne wrote:
'foreign export' doesn't work with ghc-4.00 just yet, use ghc-3.03
if you need it.
Aargl... Versionitis at its worst:
panne:~/tst linux-303/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version 3.03, patchlevel 0
panne:~/tst linux-303/bin/ghc -c -fglasgow-exts Test.hs
DsCCall.lhs:279: Irrefutable pattern failed for pattern [ioOkDataCon, ioFailDataCon]
panne:~/tst /soft/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version proto-3.03-2-Aug, patchlevel 0
panne:~/tst /soft/bin/ghc -c -fglasgow-exts Test.hs
Test.hs:11:35: parse error on input: "::"
panne:~/tst linux-400/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version 4.00, patchlevel 0
panne:~/tst linux-400/bin/ghc -c -fglasgow-exts Test.hs
ghc: module version changed to 1; reason: no old .hi file
/tmp/ghc15405.hc:118: macro `STK_CHK' used with too many (7) args
I *really* want a single, all-in-one GHC! :'-( I don't dare to test
which one of the above systems supports MPC, the new RTS, ... At least I
have the choice which part should fail: Desugarer, parser or gcc. :-}
\begin{sarcasm}
Hmm, this strongly reminds me of the current Java situation: "For
these classes you need at least JDK 1.1.4 or higher, but on Linux
1.1.6 does not work under KDE. On Solaris, 1.1.5 is highly recommended.
Blah blah..." It seems that the GHC people have learned their lessons
from the commercially successful languages...
\end{sarcasm}
Totally confused,
Sven
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Re: GHC 4.00 bugs
Simon Marlow wrote:
Sven Panne [EMAIL PROTECTED] writes:
[...]
What about the promised self-adjusting heap in the new RTS? I hoped
no -H/-K has to be used with the shiny new RTS... :-(
[...]
Remember, you compiled 4.00 with 3.03 - that's why the -H option is
still needed.
[...]
Uh oh, I forgot... :-}
I was expecting a bug report about CgBindery.hi-boot - you have to
replace some () with {} to bootstrap.
Yep, and a "!" should probably read ".". CgRetConv.hi-boot looks wrong,
too, but strangely enough there's no complaint from GHC here!?
And another one: The compilation of ghc/lib/misc/ByteOps.lhs yields the
following warnings from gcc:
/tmp/ghc8040.hc:292: warning: implicit declaration of function `double2bytes__'
/tmp/ghc8040.hc:428: warning: implicit declaration of function `float2bytes__'
/tmp/ghc8040.hc:563: warning: implicit declaration of function `short2bytes__'
/tmp/ghc8040.hc:698: warning: implicit declaration of function `int2bytes__'
/tmp/ghc8040.hc:833: warning: implicit declaration of function `long2bytes__'
/tmp/ghc8040.hc:1207: warning: implicit declaration of function `bytes2double__'
/tmp/ghc8040.hc:1431: warning: implicit declaration of function `bytes2float__'
/tmp/ghc8040.hc:1623: warning: implicit declaration of function `bytes2short__'
/tmp/ghc8040.hc:1814: warning: implicit declaration of function `bytes2int__'
/tmp/ghc8040.hc:2005: warning: implicit declaration of function `bytes2long__'
I don't think that they are all harmless, especially the float one. Easy
cure: Add
ByteOps_HC_OPTS += '-\#include"cbits/ByteOps.h"'
to ghc/lib/misc/Makefile.
Cheers,
Sven
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Re: GHC 4.00 bugs
Sven Panne [EMAIL PROTECTED] writes:
* Some "classic" warnings in ghc/rts:
/usr/include/stdlib.h:149: warning: no previous prototype for `strtold'
Hmm, perhaps I should better not mention my fix, otherwise Simon
gets pale again... (see Sep 1st)
These go away w/ a glibc version of Linux.
* Some warnings about (almost) nested comments in gum/{HLComms,ParInit}.c:
gum/HLComms.c:125: warning: `/*' within comment
Perhaps use #ifdef 0...#endif instead of /*...*/
Harmless.
* Compiling ghc/compiler/rename/ParseIface.hs with GHC 4.00 itself
needs 40MB instead of the 30MB given in ghc/compiler/Makefile.
Hmmm, 30MB was enough when compiling 4.00 with 3.03. Even stranger:
What about the promised self-adjusting heap in the new RTS? I hoped
no -H/-K has to be used with the shiny new RTS... :-(
using -dcore-lint cuts down the residency. This is a space leak we're
looking into.
Remember, you compiled 4.00 with 3.03 - that's why the -H option is
still needed. In the bootstrapped version you can forget about -H,
unless you need more than 64M heap!
* In the boostrapping phase (4.00 with 4.00), there are some strange
warnings from gcc, but only on some files, e.g.
basicTypes/Var.lhs
types/Type.lhs
typecheck/TcEnv.lhs
typecheck/TcHsSyn.lhs
typecheck/Inst.lhs
gcc complained:
/home/inst/glasgow/linux/bin/ghc -cpp -fglasgow-exts -Rghc-timing -I.
-IcodeGen -InativeGen -Iparser
-iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:reader:profiling:parser:nativeGen
-recomp -H10m -c typecheck/TcEnv.lhs -o typecheck/TcEnv.o -osuf o
ghc: 271383260 bytes, 95 GCs, 2432854/3116888 avg/max bytes residency (5
samples), 0.03 INIT (0.00 elapsed), 13.31 MUT (15.00 elapsed), 4.39 GC (4.72 elapsed)
:ghc
ghc: module version changed to 1; reason: no old .hi file
/tmp/ghc6681.hc:3700: warning: `c6BS_closure' was declared `extern' and
later `static'
/tmp/ghc6681.hc:4010: warning: `c6C2_closure' was declared `extern' and
later `static'
/tmp/ghc6681.hc:4163: warning: `c6C7_closure' was declared `extern' and
later `static'
Hmm, should be harmless, but I'll look into it.
I was expecting a bug report about CgBindery.hi-boot - you have to
replace some () with {} to bootstrap.
Sorry for the terse message, I'm on a *really* slow dialup link at the
moment.
Cheers,
Simon
--
Simon Marlow [EMAIL PROTECTED]
University of Glasgow http://www.dcs.gla.ac.uk/~simonm/
finger for PGP public key
GHC 4.00 bug
The following bug occurred while compiling GHC-4.00 on a Linux
platform, using ghc-3.03, gcc-2.7.3.2
Thanks
Ed
-
ghc-3.03 -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen
-Iparser
-iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:reader:profiling:parser:nativeGen
-recomp -O -H32m-c hsSyn/HsDecls.lhs -o hsSyn/HsDecls.o -osuf o
HsDecls.lhs:10: Warning:
Failed to find (optional) interface decl for
`s6CV'
desired at
HsBinds.hi:60
HsDecls.lhs:10: Warning:
Failed to find (optional) interface decl for
`s6CV'
desired at
HsBinds.hi:60
HsDecls.lhs:10: Warning:
Failed to find (optional) interface decl for
`s6CV'
desired at
HsBinds.hi:60
panic! (the `impossible' happened):
tcLookupTyVar: HsBinds.s6CV{-r3qc-}
Please report it as a compiler bug to
[EMAIL PROTECTED]
make[2]: *** [hsSyn/HsDecls.o] Error 1
Re: undocumented feature in GHC-4.00?
Simon Peyton-Jones wrote: When attempting to reconstruct the syntax for existential quantification, I tried: newtype Groo a = Groo (Either a b) To my surprise, using ghc-4.00, this worked - without even using `-fglasgow-exts'. (it doesn't work, with or without `-fglasgow-exts' under 3.02) Nothing about existentials here. GHC is universally quantifying over the 'b'. It's just as if you'd written newtype Groo a = Groo (forall b. Either a b) Indeed - it wasn't the type I was casting about for - I was looking for how to express: newtype Groo a = forall b. Groo (Either a b) This form of quantification seems to only be supported for `data' decls - is there a reason we can't also do it with `newtype'? Perhaps we shouldn't do implicit universal quantification here? Is this a feature or a bug? The confusion on my part was that this form of implicit universal quantification seems to be an undocumented feature. In the release notes, the only comment about implicit quantification is this: Notice that you don't need to use a forall if there's an explicit context. For example in the first argument of the constructor MkSwizzle, an implicit "forall a." is prefixed to the argument type. The implicit forall quantifies all type variables that are not already in scope, and are mentioned in the type quantified over --Jeff
RE: build errors in ghc-current-src (ghc-4.00)
matt [mailto:[EMAIL PROTECTED]] writes: Hiya Simon, I've just download the ghc-current-src.tar.gz file and tried to build a new ghc. The configure went alright, but when it came time to do a gmake boot I get the attached error messages. Is this a problem in the distribution, or something that I have missed out about? I had a look on your webpages for a patch but didn't see anything. I'm compiling using a prebuilt ghc-2.10, on a Pentium/Linux machine with 32M ram and ~100M swap. I've even copied PrelArr.lhs into the ghc-2.10 doesn't have PrelArr, which Outputable insists on getting at. Safest bet would be to upgrade to ghc-3.02 and have another go. Meanwhile I'll have a go at tweaking the compiler sources to make them ghc-2.10 friendly (it should be.) --Sigbjorn
build errors in ghc-current-src (ghc-4.00)
Hiya Simon, I've just download the ghc-current-src.tar.gz file and tried to build a new ghc. The configure went alright, but when it came time to do a gmake boot I get the attached error messages. Is this a problem in the distribution, or something that I have missed out about? I had a look on your webpages for a patch but didn't see anything. I'm compiling using a prebuilt ghc-2.10, on a Pentium/Linux machine with 32M ram and ~100M swap. I've even copied PrelArr.lhs into the thanks -- Matthew Love Command Control Information Systems ADI Limited, Systems Group Phone +61 8 9333 8936 (wk) +61 8 9272 5227 (hm) Fax +61 8 9333 8889 mailto:[EMAIL PROTECTED] ghc -M -optdep-f -optdep.depend -optdep-o -optdepo-cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:reader:profiling:parser:nativeGen -recomp parser/U_binding.hs parser/U_constr.hs parser/U_either.hs parser/U_entidt.hs parser/U_list.hs parser/U_literal.hs parser/U_maybe.hs parser/U_pbinding.hs parser/U_qid.hs parser/U_tree.hs parser/U_ttype.hs utils/Argv.lhs utils/Bag.lhs utils/BitSet.lhs utils/Digraph.lhs utils/DirUtils.lhs utils/FastString.lhs utils/FiniteMap.lhs utils/ListSetOps.lhs utils/Maybes.lhs utils/OrdList.lhs utils/Outputable.l hs utils/Pretty.lhs utils/PrimPacked.lhs utils/SST.lhs utils/StringBuffer.lhs utils/UniqFM.lhs utils/UniqSet.lhs utils/Util.lhs basicTypes/BasicTypes.lhs basicTypes/Const.lhs basicTypes/DataCon.lhs basicTypes/Demand.lhs basicTypes/FieldLabel.lhs basicTypes/Id.lhs bas! icTypes/IdInfo.lhs basicTypes/MkId.lhs basicTypes/Name.lhs basicTypes/NameSet.lhs basicTypes/PprEnv.lhs basicTypes/SrcLoc.lhs basicTypes/UniqSupply.lhs basicTypes/Unique.lhs basicTypes/Var.lhs basicTypes/VarEnv.lhs basicTypes/VarSet.lhs types/Class.lhs types/PprType.lhs types/TyCon.lhs types/Type.lhs types/Unify.lhs hsSyn/HsBasic.lhs hsSyn/HsBinds.lhs hsSyn/HsCore.lhs hsSyn/HsDecls.lhs hsSyn/HsExpr.lhs hsSyn/HsImpExp.lhs hsSyn/HsMatches.lhs hsSyn/HsPat.lhs hsSyn/HsPragmas.lhs hsSyn/HsSyn.lhs hsSyn/HsTypes.lhs prelude/PrelInfo.lhs prelude/PrelMods.lhs prelude/PrelVals.lhs prelude/PrimOp.lhs prelude/PrimRep.lhs prelude/TysPrim.lhs prelude/TysWiredIn.lhs rename/Rename.lhs rename/RnBinds.lhs rename/RnEnv.lhs rename/RnExpr.lhs rename/RnHsSyn.lhs rena me/RnIfaces.lhs rename/RnMonad.lhs rename/RnNames.lhs rename/RnSource.lhs typecheck/Inst.lhs typecheck/TcBinds.lhs typecheck/TcClassDcl.lhs typecheck/TcDefaults.lhs typecheck/TcD .lhs simplCore/SAT.lhs simplCore/SATMonad.lhs simplCore/SetLevels.lhs simplCore/SimplCore.lhs simplCore/SimplMonad.lhs simplCore/SimplUtils.lhs simplCore/Simplify.lhs stranal/SaAbsInt.lhs stranal/SaLib.lhs stranal/StrictAnal.lhs stranal/WorkWrap.lhs stranal/WwLib.lhs stgSyn/CoreToStg.lhs stgSyn/StgLint.lhs stgSyn/StgSyn.lhs simplStg/LambdaLift.lhs simplStg/SRT.lhs simplStg/SimplStg.lhs simplStg/StgStats.lhs simplStg/StgVarInfo.lhs simplStg/UpdAnal.lhs codeGen/CgBindery.lhs codeGen/CgCase.lhs codeGen/CgClosure.lhs codeGen/CgCon.lhs codeGen/CgConTbls.lhs codeGen/CgExpr.lhs codeGen/CgHeapery.lhs codeGen/CgLetNoEscape.lhs codeGen/CgMonad.lhs codeGen/CgRetConv.lhs codeGen/CgStackery.lhs codeGen/CgTailCall.lhs codeGen/CgUpdate.lhs codeGen/CgUsages.lhs codeGen/ClosureInfo.lhs codeGen/CodeGen.lhs codeGen/SM! Rep.lhs absCSyn/AbsCSyn.lhs absCSyn/AbsCUtils.lhs absCSyn/CLabel.lhs absCSyn/CStrings.lhs absCSyn/CallConv.lhs absCSyn/Costs.lhs absCSyn/PprAbsC.lhs main/CmdLineOpts.lhs main/Constants.lhs main/ErrUtils.lhs main/M ain.lhs main/MkIface.lhs reader/Lex.lhs reader/PrefixSyn.lhs reader/PrefixToHs.lhs reader/RdrHsSyn.lhs reader/ReadPrefix.lhs profiling/CostCentre.lhs profiling/SCCfinal.lhs parser/UgenAll.lhs parser/UgenUtil.lhs nativeGen/AbsCStixGen.lhs nativeGen/AsmCodeGen.lhs nativeGen/AsmRegAlloc.lhs nativeGen/MachCode.lhs nativeGen/MachMisc.lhs nativeGen/MachRegs.lhs nativeGen/PprMach.lhs nativeGen/RegAllocInfo.lhs nativeGen/Stix.lhs nativeGen/StixInfo.lhs nativeGen/StixInteger.lhs nativeGen/StixMacro.lhs nativeGen/StixPrim.lhs rename/ParseIface.hs This is GHC 2.10 - [CONTROL VERSION] No file `PrelArr.hi', `PrelArr.lhs', `PrelArr.hs' (reqd from file `utils/Outputable.lhs') among import directories: utils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:reader:profiling:parser:nativeGen:. cpp: output pipe has been closed gmake[2]: *** [depend] Error 1 gmake[1]: *** [boot] Error 1 gmake: *** [boot] Error 1 [1] + exit 2 gmake boot mattl 8
problem building pre-GHC-4.00/2 (PrimPacked.lhs)
I'm trying to build pre-GHC-4.00/2 on Cygwin B19 with GHC-3.03.
I get the following error:
==fptools== make all --unix --no-print-directory -r;
in /install/ghc-pre-4.00.2/fptools/ghc/compiler
ghc-3.03 -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser
-iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:spe
cialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:reader:profil
ing:parser:nativeGen -recomp -fvia-C -monly-3-regs -optC-funfolding-interf
ace-threshold10 -v -c utils/PrimPacked.lhs -o utils/PrimPacked.o -osuf o
The Glorious Glasgow Haskell Compilation System, version 3.03, patchlevel 0
literate pre-processor:
echo '#line 1 "utils/PrimPacked.lhs"' /tmp/ghc1016.lpp
/gw19/usr/lib/ghc-3.03/unlit utils/PrimPacked.lhs - /tmp/ghc1016.lpp
0.04user 0.03system 0:00.22elapsed 31%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
Effective command
line: -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -i
utils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specia
lise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:reader:profiling
:parser:nativeGen -recomp -fvia-C -monly-3-regs -optC-funfolding-interface-t
hreshold10 -v -c -o utils/PrimPacked.o -osuf o
Haskellised C pre-processor:
echo '{-# LINE 1 "utils/PrimPacked.lhs" -}' /tmp/ghc1016.cpp
/gw19/usr/lib/ghc-3.03/hscpp -v -D__HASKELL1__=4 -D__GLASGOW_HASKELL__=303
-I. -I. -IcodeGen -InativeGen -Iparser -I/gw19/usr/lib/ghc-3.03/includes -I/
gw19/usr/lib/ghc-3.03/includes /tmp/ghc1016.lpp /tmp/ghc1016.cpp
0.04user 0.06system 0:00.17elapsed 58%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
hscpp:CPP invoked:
/gw19/H-i386-cygwin32/lib/gcc-lib/i386-cygwin32/2.7-B19/cpp.exe -traditional
-D__HASKELL1__=4 -D__GLASGOW_HASKELL__=303 -I. -I. -IcodeGen -InativeGen -I
parser -I/gw19/usr/lib/ghc-3.03/includes -I/gw19/usr/lib/ghc-3.03/includes
/tmp/ghc1016.lpp
ghc-3.03:compile:Output file utils/PrimPacked.o doesn't exist
ghc-3.03:compile:Interface file utils/PrimPacked.hi doesn't exist
ghc-3.03:recompile:Input file utils/PrimPacked.lhs newer than
utils/PrimPacked.o
Haskell compiler:
/gw19/usr/lib/ghc-3.03/hsc ,-N ,-W
,/tmp/ghc1016.cpp -fglasgow-exts -funfolding-interface-threshold10 -fignore
-interface-pragmas -fomit-interface-pragmas -fsimplify
-ffloat-lets-exposing-whnf -ffloat-primops-ok -fcase-of-case -fdo-case-elim
-freuse-con -fpedantic-bottoms -fclone-binds -fmax-simplifier-iterations4
] -fwarn-overlapping-patterns -fwarn-missing-methods -fwarn-duplicate-expo
rts -fhi-version=303 -himap=utils%.hi:basicTypes%.hi:types%.hi:hsSyn%.hi:pre
lude%.hi:rename%.hi:typecheck%.hi:deSugar%.hi:coreSyn%.hi:specialise%.hi:sim
plCore%.hi:stranal%.hi:stgSyn%.hi:simplStg%.hi:codeGen%.hi:absCSyn%.hi:main%
.hi:reader%.hi:profiling%.hi:parser%.hi:nativeGen%.hi:.%.hi:/gw19/usr/lib/gh
c-3.03/imports/exts%.hi:/gw19/usr/lib/ghc-3.03/imports/exts%.hi:/gw19/usr/li
b/ghc-3.03/imports/std%.hi -v -hifile=/tmp/ghc1016.hi -C=/tmp/ghc1016.hc -
F=/tmp/ghc1016_stb.c -FH=/tmp/ghc1016_stb.h
+RTS -H600 -K100 -s/tmp/ghc1016.stat
Glasgow Haskell Compiler, version3.03, for Haskell 1.4
PrimPacked.lhs:135: Data constructor not in scope: `ForeignObj'
PrimPacked.lhs:256: Data constructor not in scope: `ForeignObj'
Compilation had errors
Command exited with non-zero status 1
5.56user 0.82system 0:09.22elapsed 69%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
deleting... /tmp/ghc1016.lpp /tmp/ghc1016.cpp /tmp/ghc1016.hi
/tmp/ghc1016.hc /tmp/ghc1016_stb.c /tmp/ghc1016_stb.h /tmp/ghc1016.stat
rm -f /tmp/ghc1016*
make[2]: *** [utils/PrimPacked.o] Error 1
make[1]: *** [all] Error 1
make: *** [all] Error 1
I guess that PrimPached.lhs need Prelude from ghc-4.00 but get it from 3.03.
Am i right?
Any hints?
Thanks a lot,
Alex
RE: problem building pre-GHC-4.00/2 (PrimPacked.lhs)
Alex Verbitsky [EMAIL PROTECTED] writes: I'm trying to build pre-GHC-4.00/2 on Cygwin B19 with GHC-3.03. I get the following error: ... Glasgow Haskell Compiler, version3.03, for Haskell 1.4 PrimPacked.lhs:135: Data constructor not in scope: `ForeignObj' PrimPacked.lhs:256: Data constructor not in scope: `ForeignObj' Compilation had errors Yep, the pre-4.00 sources are not compatible with 3.03 in a couple of minor (but crucial) ways, I'm afraid. The release of ghc-4.00, which fixes this prob., is only days away though. --Sigbjorn
Re: Building documentation (GHC 4.00)
"Manuel M. T. Chakravarty" [EMAIL PROTECTED] writes:
expand installing.vsgml | ../glafp-utils/sgmlverb/sgmlverb installing.sgml
sgml2info installing.sgml
Processing file installing.sgml
Making info file `installing.info' from `/tmp/sgmltmp.installing29856.info.2'.
/tmp/sgmltmp.installing29856.info.2:53: Misplaced {.
/tmp/sgmltmp.installing29856.info.2:53: Misplaced }.
/tmp/sgmltmp.installing29856.info.2:75: Misplaced {.
continues like that
This one is a known bug in the SGML tools. It's been reported to them
on numerous occasions. Info documentation is pretty much hosed at the
moment - but html is better anyway.
nomi ROOT 1049 (.../fptools/docs)# make ps
expand installing.vsgml | ../glafp-utils/sgmlverb/sgmlverb installing.sgml
sgml2latex -m --output=tex installing.sgml
Processing file installing.sgml
../glafp-utils/ltx/ltx installing.tex
This is TeX, Version 3.14159 (C version 6.1)
(installing.tex
LaTeX2e 1996/12/01 patch level 1
Babel v3.6h and hyphenation patterns for american, german, loaded.
(/usr/lib/texmf/texmf/tex/latex/base/article.cls
Document Class: article 1996/10/31 v1.3u Standard LaTeX document class
(/usr/lib/texmf/texmf/tex/latex/base/size10.clo))
Writing index file installing.idx
! LaTeX Error: File `linuxdoc-sgml.sty' not found.
Type X to quit or RETURN to proceed,
or enter new name. (Default extension: sty)
I checked and the file `linuxdoc-sgml.sty' is definitely
contained in my LinuxDoc distribution. Do you require to
actually copy the file into the teTeX tree?
No, that shouldn't be necessary, but it could be a mis-installation of
the SGML tools. Make sure you have the latest version (1.0.7
according to the web page at http://www.sgmltools.org/), and try
re-installing it.
Cheers,
Simon
--
Simon Marlow [EMAIL PROTECTED]
University of Glasgow http://www.dcs.gla.ac.uk/~simonm/
finger for PGP public key
Building documentation (GHC 4.00)
I hit some problems when trying to format the documentation
contained in the 4.00 source bundle -- however, I think,
this is not 4.00-specific. I am not sure whether this is a
bug or just a stupid-operator error.
I am working on a 2.0.33 Linux system that has the LinuxDoc
tools 1.5 and teTeX 0.4 installed (out of the box). However
I neither manage to build the info files nor the ps files.
(Searching through `installing.sgml', I also didn't find any
description on how to build the documentation.) The
following are logs of the problems that I get in
`fptools/docs/':
nomi ROOT 1048 (.../fptools/docs)# make info
expand installing.vsgml | ../glafp-utils/sgmlverb/sgmlverb installing.sgml
sgml2info installing.sgml
Processing file installing.sgml
Making info file `installing.info' from `/tmp/sgmltmp.installing29856.info.2'.
/tmp/sgmltmp.installing29856.info.2:53: Misplaced {.
/tmp/sgmltmp.installing29856.info.2:53: Misplaced }.
/tmp/sgmltmp.installing29856.info.2:75: Misplaced {.
continues like that
and
nomi ROOT 1049 (.../fptools/docs)# make ps
expand installing.vsgml | ../glafp-utils/sgmlverb/sgmlverb installing.sgml
sgml2latex -m --output=tex installing.sgml
Processing file installing.sgml
../glafp-utils/ltx/ltx installing.tex
This is TeX, Version 3.14159 (C version 6.1)
(installing.tex
LaTeX2e 1996/12/01 patch level 1
Babel v3.6h and hyphenation patterns for american, german, loaded.
(/usr/lib/texmf/texmf/tex/latex/base/article.cls
Document Class: article 1996/10/31 v1.3u Standard LaTeX document class
(/usr/lib/texmf/texmf/tex/latex/base/size10.clo))
Writing index file installing.idx
! LaTeX Error: File `linuxdoc-sgml.sty' not found.
Type X to quit or RETURN to proceed,
or enter new name. (Default extension: sty)
I checked and the file `linuxdoc-sgml.sty' is definitely
contained in my LinuxDoc distribution. Do you require to
actually copy the file into the teTeX tree?
Thanks in advance for any comments,
Manuel
Re: GHC 4.00 Hackers only release
Just a little bit of nit picking in ghc-pre-4.00.2:
* PROTO is not defined by GHC's headers anymore, therefore the
compilation of Readline.lhs fails.
* readline/history.h is not included.
* Prototypes for bcopy/bzero are missing.
* GHC somehow manages to generate the following warning while
compiling the RTS:
/usr/include/stdlib.h:149: warning: no previous prototype for `strtold'
This is simply cured by -D_GNU_SOURCE.
---
*** fptools/ghc/lib/misc/cbits/ghcReadline.h.~1~Mon Feb 2 18:32:20 1998
--- fptools/ghc/lib/misc/cbits/ghcReadline.hTue Sep 1 09:55:33 1998
***
*** 5,11
#include "config.h"
#if HAVE_READLINE_READLINE_H
! #include "readline/readline.h"
#endif
/* For some reason the following 3 aren't defined in readline.h */
--- 5,12
#include "config.h"
#if HAVE_READLINE_READLINE_H
! #include readline/readline.h
! #include readline/history.h
#endif
/* For some reason the following 3 aren't defined in readline.h */
***
*** 17,23
/* Our C Hackery stuff for Callbacks */
typedef I_ KeyCode;
extern StgStablePtr cbackList;
! I_ genericRlCback PROTO((I_, I_));
extern StgStablePtr haskellRlEntry;
extern I_ current_narg, rl_return;
extern KeyCode current_kc;
--- 18,24
/* Our C Hackery stuff for Callbacks */
typedef I_ KeyCode;
extern StgStablePtr cbackList;
! I_ genericRlCback (I_, I_);
extern StgStablePtr haskellRlEntry;
extern I_ current_narg, rl_return;
extern KeyCode current_kc;
*** fptools/ghc/lib/misc/cbits/md5.h.~1~Fri Aug 7 12:04:03 1998
--- fptools/ghc/lib/misc/cbits/md5.hTue Sep 1 09:55:19 1998
***
*** 2,7
--- 2,11
#ifndef _MD5_H
#define _MD5_H
+ #if HAVE_STRING_H
+ #include string.h
+ #endif
+
typedef unsigned long word32;
typedef unsigned char byte;
*** fptools/ghc/driver/ghc.lprl.~1~ Tue Aug 25 13:11:36 1998
--- fptools/ghc/driver/ghc.lprl Tue Sep 1 10:16:54 1998
***
*** 246,252
\begin{code}
$CcRegd = $GHC_OPT_HILEV_ASM;
! @CcBoth_flags = ('-S','-Wimplicit'); # flags for *any* C compilation
@CcInjects= ();
# GCC flags:
--- 246,252
\begin{code}
$CcRegd = $GHC_OPT_HILEV_ASM;
! @CcBoth_flags = ('-S','-Wimplicit','-D_GNU_SOURCE'); # flags for *any* C
compilation
@CcInjects= ();
# GCC flags:
---
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Re: GHC 4.00 Hackers only release
Kevin Glynn writes:
Simon Marlow writes:
This is pre-release of the long awaited GHC 4.00. I decided to put
together a release today because the sources are in pretty good shape
at the moment, not because it is at all ready. In particular, we plan
to have some sort of profiling working for the real 4.00 release.
The source snapshot can be found at
ftp://ftp.dcs.gla.ac.uk/pub/haskell/glasgow/working/ghc-pre-4.00.tar.gz
Have Fun!
Actually:
ftp://ftp.dcs.gla.ac.uk/pub/haskell/glasgow/working/ghc-pre-4.00-src.tar.gz
There was a couple of minor problems with that tarball, so I've rolled
another one that hopefully simplifies the path to ghc-4.00 happiness.
Try
ftp://ftp.dcs.gla.ac.uk/pub/haskell/glasgow/working/ghc-pre-4.00.1-src.tar.gz
--Sigbjorn
For those keeping track / don't want to download it all again, the
changes in this bundle were:
- removed ghc/driver/ghc
- removed ghc/compiler/parser/tree.{c,h}
- removed ghc/compiler/parser/hslexer.c
- removed ghc/compiler/parser/hsparser.tab.{c,h}
- added mk/config.h.in
- turn off the building of profiling libs by default, since
the profiling bits in the rts doesn't compile cleanly:
*** fptools-4.00/mk/config.mk.inFri Aug 21 13:35:43 1998
--- fptools/mk/config.mk.in Sat Aug 29 16:42:13 1998
***
*** 208,212
GhcLibWays=
else
! GhcLibWays=p
endif
--- 208,212
GhcLibWays=
else
! GhcLibWays=
endif
- configure.in: changed default WithGhcHc from ghc-2.10 to
ghc-3.02, since the compiler sources doesn't compile
cleanly with 2.10 at the moment:
*** fptools-4.00/configure.in Fri Aug 21 13:35:26 1998
--- fptools/configure.inSat Aug 29 16:48:13 1998
***
*** 287,296
AC_ARG_WITH(ghc-hc,
[ --with-ghc-hc=haskell compiler
! Use a command different from 'ghc-2.10' to compile up the GHC compiler
sources.
(no claims currently made that this will work with a compiler other than a
recent version of GHC, but you could always try...)
],
[WithGhcHc="$withval"],
! [WithGhcHc="ghc-2.10"]
)
AC_SUBST(WithGhcHc)
--- 287,296
AC_ARG_WITH(ghc-hc,
[ --with-ghc-hc=haskell compiler
! Use a command different from 'ghc-3.02' to compile up the GHC compiler
sources.
(no claims currently made that this will work with a compiler other than a
recent version of GHC, but you could always try...)
],
[WithGhcHc="$withval"],
! [WithGhcHc="ghc-3.02"]
)
AC_SUBST(WithGhcHc)
- misc ghc/rts/gmp Makefile fixes to make gmp source build properly.
*** fptools-4.00/ghc/rts/gmp/Makefile.inFri Aug 21 15:48:47 1998
--- fptools/ghc/rts/gmp/Makefile.in Sat Aug 29 17:49:45 1998
***
*** 193,196
force:
! .PNONY: check install install-bsdmp install-info-files install-strip uninstall
.PHONY: doc clean distclean maintainer-clean force info dvi
--- 193,204
force:
! .PHONY: check install install-bsdmp install-info-files install-strip uninstall
.PHONY: doc clean distclean maintainer-clean force info dvi
+
+ # added sof.
+ .SUFFIXES: .o .c
+ # In the fptools/ mk setup we clear the setting of .SUFFIXES since we
+ # don't use any pre-supplied suffix rules (if any). This causes a
+ # problem when descending into a directory like gmp/ which does
+ # use suffix rules, so we need to add .c .o to the .SUFFIXES list
+ # here.
*** fptools-4.00/ghc/rts/gmp/mpz/Makefile.inFri Aug 21 15:50:28 1998
--- fptools/ghc/rts/gmp/mpz/Makefile.in Sat Aug 29 15:40:01 1998
***
*** 78,82
clean mostlyclean:
rm -f *.o libmpz.a
! -cd tests; $(MAKE) $@
distclean maintainer-clean: clean
rm -f Makefile config.status
--- 78,82
clean mostlyclean:
rm -f *.o libmpz.a
! #-cd tests; $(MAKE) $@
distclean maintainer-clean: clean
rm -f Makefile config.status
