Possibly ancient history non-compliance.
ghc-4.04 and ghc-4.08 both complain about the following: No instance for `Show HandlePosn' But according to the report, they should be showable (if precious little else). Haven't a version of 5.00 to hand (but will be installing 5.02, promise!) so I haven't checked if this has changed since. Cheers, Alex. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
No Subject
The Sender field should be ignored (as per RFC 822) by mail software if there's a From field. The first From field is not legal as it is not delimited by a ':' I'd say the Pine setup is wrong. --Sigbjorn
RE: ghc-4.03 on cynwin deriving oddity.
It's a bug, which is fixed in 4.04 Ah-hah... (I could likely have tested this myself, had I had the gumption...) (a Win32 version of which is due out shortly.) Excellent. For one scary moment thoughts like 'Windoze build from source' were going through my head. Cheers, Alex.
Re: Building GHC on a PPC Mac
From UNKNOWN Received: from joyce.ucc.ie by vanuata with SMTP (MMTA) with ESMTP; Tue, 12 Oct 1999 15:45:59 +0100 Received: (from abf@localhost) by joyce.ucc.ie (8.7.3/8.7.3) id PAA11955 for [EMAIL PROTECTED]; Tue, 12 Oct 1999 15:45:02 +0100 (BST) [This is a resend; forwarding from '[EMAIL PROTECTED]' seems to be highly unwell.] Observe: BASH.EXE-2.02$ cat Enum.hs enumerate :: (Enum a, Bounded a) = [a] enumerate = [minBound .. maxBound] data Test = Foo | Bar | Blah | Nonsense deriving (Show, Enum, Bounded) main = print (enumerate :: [Test]) BASH.EXE-2.02$ ghc-4.03 -static Enum.o BASH.EXE-2.02$ ./a.exe [Foo,Foo,Foo,Foo] Whereas, with ghc-4.02, under Solaris 2.5: yeats.ucc.ie:~/LVO: a.out [Foo,Bar,Blah,Nonsense] What, as they say, gives? Cheers, Alex.
Re: ghc-4.03 on cynwin deriving oddity.
enumerate :: (Enum a, Bounded a) = [a] enumerate = [minBound .. maxBound] data Test = Foo | Bar | Blah | Nonsense deriving (Show, Enum, Bounded) main = print (enumerate :: [Test]) BASH.EXE-2.02$ ghc-4.03 -static Enum.o BASH.EXE-2.02$ ./a.exe [Foo,Foo,Foo,Foo] To be a tad more specific, the problem is the derived toEnum, which defines toEnum 0 = Foo, toEnum 1 = Foo ... Cheers, Alex.
ghc-4.04, Alpha.
In order to install ghc-4.04, I need to install the binary v. of 2.10 (this should be OK for doing that, right?) Immediately I come a cropper, thus: wisdom.ucc.ie:~/ghc210/fptools: gnumake in-place gnumake config-pkgs bindir=`pwd`/bin/alpha-dec-osf1/ghc-2.10 libdir=`pwd`/lib/alpha-dec-osf1 datadir=`pwd`/share/ghc-2.10 gnumake[1]: Entering directory `/usr/local/users/abf/ghc210/fptools' Configuring ghc, version 2.10, on alpha-dec-osf1 ... Creating a configured version of ghc .. Done. Creating a configured version of stat2resid .. Done. Creating a configured version of hstags .. Done. Creating a configured version of mkdependHS .. Done. Creating a configured version of hscpp .. Done. /bin/sh: syntax error at line 1: `;' unexpected gnumake[1]: *** [config-pkgs] Error 2 gnumake[1]: Leaving directory `/usr/local/users/abf/ghc210/fptools' gnumake: *** [in-place] Error 2 If this is an Alpha shell version blooper, it's not clear to me where and how to fix it: redefining SH = /bin/bash in the Makefile certainly didn't help. Also, I've been hacking my way around needing happy 1.6; I think I can 'fake' this, but it ain't gonna be pretty. Better suggestions gratefully received. Cheers, Alex.
Re: ghc-4.04, Sun Solaris 2.5.
I wrote:
syntax error at ../../ghc/driver/ghc line 1855, near "sub runLinker("
Execution of ../../ghc/driver/ghc aborted due to compilation errors.
gnumake: *** [Adjustor.o] Error 255
Evidently Perl versionitis. 5.001 no like; 5.005 likum plenty fine.
(This seems familiar, but I didn't notice an installation caveats
beyond using any-old Perl 5.)
Cheers,
Alex.
ghc-4.04, Sun Solaris 2.5.
yeats.ucc.ie:~/ghc44/build/ghc/rts: gnumake all
../../ghc/driver/ghc -I../includes -I. -Igum -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations
-optc-Winline -optc-Waggregate-return -optc-Wpointer-arith
-optc-Wbad-function-cast -O2 -optc-DCOMPILING_RTS -static -O2
-optc-fomit-frame-pointer-c Adjustor.c -o Adjustor.o
syntax error at ../../ghc/driver/ghc line 1855, near "sub runLinker("
Execution of ../../ghc/driver/ghc aborted due to compilation errors.
gnumake: *** [Adjustor.o] Error 255
Thoughts?
Cheers,
Alex.
ghc-4.03/cygwin catch-33.
Program won't compile in default max heap; -H objects that I should instead use -M, to raise same; -M isn't a recognised option. Fixing any one of these would do. ;-) (If it's fixed in 4.04 or 4.05, extra credit for a binary build: I've just about maxed out on Windows tinkering for the week (and it's only Tuesday)...) (Incidentally, it's falling over on the simplifier, on a very non-complex module, which seems odd. (One huge datavalue, basically.) Traditionally, though, when this is a problem, tweaking simplifier flags to help just means it falls over on code-gen instead.) Cheers, Alex.
RE: Message repeats: Alleged WinTel v4.03 bugs?
'getEnv "PATH"' returns, not the value of PATH, but the whole environment. Which is also handy, but not what I understood the report to specify, and not what ghc-4.02 does on this 'ere Sun. Can someone comment on (esp.) the second of these? Is this reproducible, is it the case _only_ on Win32, and, is it/will it be fixed in 4.04, or thereafter? (In the meantime, I guess a work-around is fairly obvious.) Can't reproduce this here with 4.03pl1 (win32). Me neither. D'oh. I encountered a quite _different_ problem instead (I'll report this as best I can, later, but it seems highly difficult to reproduce in a simple example), but this one seems to have entirely 'gone away', to the point of making me doubt my sanity. Or at least my original 'experiment'. Re: first point, the generated .hc files aren't ANSI conformant, so I'm surprised it has worked in other contexts. I haven't tried as recent a version of ghc under Solaris, so it may be versionitis, rather than platformitis. Cheers, Alex.
Alleged WinTel v4.03 bugs?
Two oddities I've noticed with ghc-4.03, win+cygnus binary build: The -ansi flag makes gcc go berserk on the generated code. I stopped. 'getEnv "PATH"' returns, not the value of PATH, but the whole environment. Which is also handy, but not what I understood the report to specify, and not what ghc-4.02 does on this 'ere Sun. Cheers, Alex.
Re: Windows NT installer works.
Mircea Draghicescu: The other question still remains: is this 4.03 or 4.04? Having recently dl'd the same thing, looks a lot like ghc-4.03 to me... I presume there's not a binary build for 4.04 (at least, not yet).
Error error.
The following is a genuine type error, but the first message appears
to be rather 'parasitic', not to mention not making any actual sense.
It's caused by having a spurious type context around a type with no
type vriables (as per the second error message, which is immaculate...)
Case.hs:378:
The constraint `PO b' does not mention any of
the universally quantified type variables {}
of the type `Metric HolidayR NumInf
- HolidayR - SetOf HolidayR - SetOf HolidayR'
In the type signature for `s_max2'
Case.hs:378:
The constraint `PO b'
mentions type variables that do not appear in the type
`Metric HolidayR NumInf
- HolidayR - SetOf HolidayR - SetOf HolidayR'
In the type signature for `s_max2'
Cheers,
Alex.
RE: Strange ghc-4.02 TC bug?
Not a typechecker bug; more a bizarre consequence of overlapping instance decls. OK, a typechecker misfeature, then, so I'll cross-reply to ghc-users. ;-) The instance decl instance Holidays a = Eq a overlaps with absolutely every other instance decl for Eq. In order to make Lattice (Inv a) an instance of Eq, we have to satisfy Eq (Inv a), since Eq is a superclass of Lattice. From the data decl, we can get Eq (Inv a) if we can get Eq a. From the instance decl you commented out, we can get Eq a if we can get Holidays a. But then we get stuck. That seems a strange thing to do, really. Isn't the (apparent) lack of an instance of Eq a, rather than it being sensible to insist that the superclasses be back-propgated (if I even remotely understand what's going on here...). Admittedly, we can also get Eq a from Lattice a, but GHC's search doesn't spot that (I'm not quite certain why). Aye, there's the rub. That's why I think it's a bug, or at least, a non-optimal resolution of the overlap. Furthermore, even if this ought to be rejected, then: a) why is it OK if the above instance declaration appears in a different module; b) why is the overlap error in the reported manner, which is _really_ confusing? (I had to pretty much use 'divide and conquer' on the source program to just localise the error, never mind understand it. Slan, Alex.
Strange ghc-4.02 TC bug?
Discern that the following program is apparently well-typed: module M2 where class Eq a = Lattice a where bottom :: a data Inv a = INV a deriving Eq instance Lattice a = Lattice (Inv a) class Holidays a where holCode :: a - Int -- instance Holidays a = Eq a Now, uncomment the last line, and suddenly: ghc-4.02 -c M2.hs -H30m -K2M -recomp -fglasgow-exts -cpp -syslib misc -Rgc-stats -dshow-passes -fmax-simplifier-iterations4 -funfolding-use-threshold-0 -optC-fallow-undecidable-instances -optC-fallow-overlapping-instances *** Reader: *** Renamer: *** TypeCheck: M2.hs:9: Warning: No explicit method nor default method for `bottom' in an instance declaration for `Lattice' M2.hs:9: Could not deduce `Holidays a' (arising from an instance declaration at M2.hs:9) from the context: (Lattice a) Probable cause: missing `Holidays a' in instance declaration context When checking the superclasses of an instance declaration What gives? Even more oddly, if this last line is moved to a different module, then the problem vanishes. Slan libh, Alex.
RE: RTS flags, at compile time?
Thanks Simon, though I'm still a tad at sea... Of course you can! Take a look at the User Guide, section 2.12: http://www.dcs.gla.ac.uk/fp/software/ghc/4.01/users_guide/users_guide-2.html #ss2.12 (under "RTS options for hackers...") That says it all, I have a nasty feeling... For a kick off, I can find neither RtsFlags.lh or rtsdefs.h files in the 4.01 distribution. Some scouting around reveals a RtsFlags.h: does that fit both bills?
RTS flags, at compile time?
Is there as yet any way to "compile in" particular RTS flags (or particular defaults), when invoking ghc? Most obviously, heap size... Slan, Alex.
RE: GHC 4.01 gmake all problem
Very strange - either/both of you fans of autoheader? Dunno about Jan or Keith, but I certainly amn't! And yet, I get the same error, and what's worse, on my first (attempted) build of the compiler. However, I did re-run configure at one point; is that the root of this particular evil? i.e., did you do autoconf ./configure --yadda or autoheader autoconf ./configure ... Enquiring minds want to know. Never have, and hopefully never will. Much as I'd like to use a --yadda flag or two... Slan, Alex.
i386-unknown-solaris2?
Has anyone out there tried to install ghc (any version whatsoever) on a PC running Solaris 2.n? Results of keen interest. Slan, Alex.
Linker problem with ghc-4.01 (s-s-s binary).
An unsuspecting little program of mine crunches out the binary distrib of 4.01, with "library -lgmp: not found" (full output appended). Any clues as to what's up here? (Apologies if this is blitheringly obvious, or just a shoddy report, about to fall into bed...) Slan, Alex. _ oconnor.ucc.ie:~/filt4: gnumake OPT=-v rm -f galileo ghc-4.01 -o galileo -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 -v TypeDefs.o Utils.o Lexer.o GenUtils.o Galileo6.o Gal2Gal.o CodeGen.o List13.o Maybe13.o Phase1.o Phase2.o Phase3.o Gal2Nat.o GalileoModules.o AlexUtil.o Struct.o Commands.o CLI.o Pareto.o RTE.o Interpret.o Skolem.o Intervals.o Trie.o Trace.o Normal.o Main.o -optl-O The Glorious Glasgow Haskell Compilation System, version 4.01, patchlevel 0 Linker: gcc -v -u PrelMain_mainIO_closure -u PrelBase_IZh_static_info -u PrelBase_CZh_static_info -u PrelBase_FZh_static_info -u PrelBase_DZh_static_info -u PrelAddr_AZh_static_info -u PrelAddr_WZh_static_info -u PrelAddr_I64Zh_static_info -u PrelAddr_W64Zh_static_info -u PrelForeign_StablePtr_static_info -u PrelBase_IZh_con_info -u PrelBase_CZh_con_info -u PrelBase_FZh_con_info -u PrelBase_DZh_con_info -u PrelAddr_AZh_con_info -u PrelAddr_WZh_con_info -u PrelAddr_I64Zh_con_info -u PrelAddr_W64Zh_con_info -u PrelForeign_StablePtr_con_info -u PrelBase_False_static_closure -u PrelBase_True_static_closure -u PrelPack_unpackCString_closure -O -o galileo TypeDefs.o Utils.o Lexer.o GenUtils.o Galileo6.o Gal2Gal.o CodeGen.o List13.o Maybe13.o Phase1.o Phase2.o Phase3.o Gal2Nat.o GalileoModules.o AlexUtil.o Struct.o Commands.o CLI.o Pareto.o RTE.o Interpret.o Skolem.o Intervals.o Trie.o Trace.o Normal.o Main.o -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -lHSexts -lHSmisc -lHSmisc_cbits -lnsl -lsocket -lHSexts -lHS -lHS_cbits -lHSrts -lgmp -lm Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/specs gcc version 2.7.2.3 /usr/ccs/bin/ld -V -Y P,/usr/ccs/lib:/usr/lib -Qy -o galileo -u PrelMain_mainIO_closure -u PrelBase_IZh_static_info -u PrelBase_CZh_static_info -u PrelBase_FZh_static_info -u PrelBase_DZh_static_info -u PrelAddr_AZh_static_info -u PrelAddr_WZh_static_info -u PrelAddr_I64Zh_static_info -u PrelAddr_W64Zh_static_info -u PrelForeign_StablePtr_static_info -u PrelBase_IZh_con_info -u PrelBase_CZh_con_info -u PrelBase_FZh_con_info -u PrelBase_DZh_con_info -u PrelAddr_AZh_con_info -u PrelAddr_WZh_con_info -u PrelAddr_I64Zh_con_info -u PrelAddr_W64Zh_con_info -u PrelForeign_StablePtr_con_info -u PrelBase_False_static_closure -u PrelBase_True_static_closure -u PrelPack_unpackCString_closure /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crt1.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crti.o /usr/ccs/lib/values-Xa.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crtbegin.o -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/ghc-4.01/lib/ghc-4.01 -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/lib TypeDefs.o Utils.o Lexer.o GenUtils.o Galileo6.o Gal2Gal.o CodeGen.o List13.o Maybe13.o Phase1.o Phase2.o Phase3.o Gal2Nat.o GalileoModules.o AlexUtil.o Struct.o Commands.o CLI.o Pareto.o RTE.o Interpret.o Skolem.o Intervals.o Trie.o Trace.o Normal.o Main.o -lHSexts -lHSmisc -lHSmisc_cbits -lnsl -lsocket -lHSexts -lHS -lHS_cbits -lHSrts -lgmp -lm -lgcc -lc -lgcc /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crtend.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crtn.o ld: Software Generation Utilities (SGU) SunOS/ELF (LK-2.0 (S/I) - versioning) ld: fatal: library -lgmp: not found ld: fatal: File processing errors. No output written to galileo real3.6 user2.9 sys 0.2 deleting... galileo rm -f /tmp/ghc12060* gnumake: *** [galileo] Error 1 oconnor.ucc.ie:~/filt4:
RE: What's happening here?
Picking up the wrong "ghc", perhaps? Hard to tell - what does 'ghc --version' report? 4.01 (which wasn't what I had intended, btw, and Simon has already avised is a Bad Idea -- more inter-machine configuration confusion on my part, sorry). What puzzled me was that it was just invoking "ghc", whereas for some reason I was expecting config to have selected ghc-some version. I may be misrembering what happened with previous versions, though (or else I configured differently). Anyhoo, reconfig with --with-ghc-hc=ghc-3.02, all seems well. Actually getting someplace now, it looks like! (Thanks for the help, especially to Simes, at the risk of tempting fate...) Slan, Alex.
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
Non-variable instance contexts.
I hate this error. Whilst arguably this is an "untested" extension to Standard Haskell, it seemed pretty sound in practice. Can't we at least have it back as a GlaExt? (MSExt?) I'm starting to feel more than a little Quaint having to use ghc-3.01, just to get my programs to compile... (If anyone has a good systematic workaround to suggest, I'm all ears.) ghc-4.00 -c Intervals.hs -H30m -K2M -recomp -fglasgow-exts -cpp -syslib misc -Rgc-stats -dshow-passes -fmax-simplifier-iterations4 -funfolding-use-threshold-0 -fvia-C Intervals.hs:460: Illegal constaint `Ord (s e)' in instance context (Instance contexts must constrain only type variables) [etc, etc] Slainte, Alex.
Re: reply to `I hate this error'
Sergey writes: Is not this due to omitting -optC-fallow-undecidable-instances -optC-fallow-overlapping-instances ? Sorry, if i am missing the point. No, I was! ;-) And thanks to Simon(s) for pointing this out, too. Mind you, I somewhat object to the "undecidable" bit: I thought the current thinking was that "simple" non-variable contexts were a sound, decidable extension? [ The proof's in the post. ;-) ] Slan, Alex.
4.00, s-s-s bug.
Here's a very cut down version of the bug-exhibiting program mentioned earlier. Sorry, if I cut it down any more, it compiles! Slan, Alex. _ swift.ucc.ie:~/filt4: ghc M.lhs MachRegs.lhs:563: Non-exhaustive patterns in function baseRegOffset swift.ucc.ie:~/filt4: cat M.lhs module M where data T = C Int f a b c d e f g h = s a b s x (C _ ) = ()
RE: 4.00, s-s-s, linker errors.
Or you may have picked up a dodgy binary dist.
That was the one... One last (?) problem... This program:
module Main where
import IOExts
main = trace "Boogger" print 1
ain't playin', as follows (maxi-spam version).
Slainte,
Alex.
_
oconnor.ucc.ie:~/filt4: ghc -v -syslib misc Trc.hs
The Glorious Glasgow Haskell Compilation System, version 4.00, patchlevel 0
Effective command line: -v -syslib misc
Ineffective C pre-processor:
echo '{-# LINE 1 "Trc.hs" -}' /tmp/ghc25004.cpp cat Trc.hs
/tmp/ghc25004.cpp
real0.0
user0.0
sys 0.0
ghc:compile:Interface file Trc.hi doesn't exist
Haskell compiler:
/usr/local/ghc-4.00/lib/ghc-4.00/hsc ,-W ,/tmp/ghc25004.cpp
-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-exports
-fhi-version=400
-himap=.%.hi:/usr/local/ghc-4.00/lib/ghc-4.00/imports/exts%.hi:/usr/local/ghc-4.
00/lib/ghc-4.00/imports/misc%.hi:/usr/local/ghc-4.00/lib/ghc-4.00/imports/exts%.
hi:/usr/local/ghc-4.00/lib/ghc-4.00/imports/misc%.hi:/usr/local/ghc-4.00/lib/ghc
-4.00/imports/std%.hi -v -hifile=/tmp/ghc25004.hi -S=/tmp/ghc25004.s -F= -FH=
+RTS -H600 -K100
Glasgow Haskell Compiler, version 4.00, for Haskell 1.4
real1.8
user1.6
sys 0.0
Pin on Haskell consistency info:
echo '
.text
hsc.Trc.hs.40.0..:' /tmp/ghc25004.s
real0.0
user0.0
sys 0.0
*** New hi file follows...
_interface_ Main 400
_instance_modules_
IO PrelAddr PrelArr PrelBounded PrelCCall PrelForeign PrelIOBase PrelNum
PrelNumExtra PrelTup
_usages_
IO 1 :: print 1;
IOExts 1 :: trace 1;
PrelBase 1 :: $dEq0 1 $dEq1 1 $dEqBool0 1 $dEqChar0 1 $dEqInt0 1 $dEqInteger0 1
$dNumInt0 1 $dShow0 1 $dShow1 1 $dShow2 1 $dShowBool0 1 $dShowChar0 1 $dShowInt0
1 $m- 1 $m/= 1 $mfromInt 1 $mshowList 1 addr2Integer 1 foldr 1 int2Integer 1
integer_0 1 integer_1 1 integer_2 1 integer_m1 1 Eq 1 Num 1 Show 1 String 1;
PrelIOBase 1 :: IO 1;
PrelNum 1 :: $dNumInteger0 1 $dShowInteger0 1;
PrelNumExtra 1 :: $dEqDouble0 1 $dNumDouble0 1 $dShowDouble0 1;
PrelPack 1 :: packCString# 1 unpackAppendCString# 1 unpackCString# 1
unpackFoldrCString# 1 unpackNBytes# 1;
_exports_
Main main;
_declarations_
main _:_ PrelIOBase.IO PrelBase.() ;;
ghc: module version unchanged at 2
Replace .hi file, if changed:
cmp -s Main.hi /tmp/ghc25004.hi-new || ( rm -f Main.hi cp
/tmp/ghc25004.hi-new Main.hi )
real0.0
user0.0
sys 0.0
Unix assembler:
gcc -o Trc.o -c -I. -I/usr/local/ghc-4.00/lib/ghc-4.00/includes
-I/usr/local/ghc-4.00/lib/ghc-4.00/includes /tmp/ghc25004.s
real0.1
user0.0
sys 0.0
Linker:
gcc -v -u PrelBase_IZh_static_info -u PrelBase_CZh_static_info -u
PrelBase_False_static_closure -u PrelBase_True_static_closure -u
PrelMain_mainIO_closure Trc.o -L/usr/local/ghc-4.00/lib/ghc-4.00
-L/usr/local/ghc-4.00/lib/ghc-4.00 -L/usr/local/ghc-4.00/lib/ghc-4.00
-L/usr/local/ghc-4.00/lib/ghc-4.00 -L/usr/local/ghc-4.00/lib/ghc-4.00
-L/usr/local/ghc-4.00/lib/ghc-4.00 -L/usr/local/ghc-4.00/lib/ghc-4.00 -lHSmisc
-lHSmisc_cbits -lnsl -lsocket -lHSexts -lHSmisc -lHSmisc_cbits -lnsl -lsocket
-lHSexts -lHS -lHS_cbits -lHSrts -lgmp -lm
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/specs
gcc version 2.7.2.3
/usr/ccs/bin/ld -V -Y P,/usr/ccs/lib:/usr/lib -Qy -u PrelBase_IZh_static_info
-u PrelBase_CZh_static_info -u PrelBase_False_static_closure -u
PrelBase_True_static_closure -u PrelMain_mainIO_closure
/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crt1.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crti.o
/usr/ccs/lib/values-Xa.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crtbegin.o
-L/usr/local/ghc-4.00/lib/ghc-4.00 -L/usr/local/ghc-4.00/lib/ghc-4.00
-L/usr/local/ghc-4.00/lib/ghc-4.00 -L/usr/local/ghc-4.00/lib/ghc-4.00
-L/usr/local/ghc-4.00/lib/ghc-4.00 -L/usr/local/ghc-4.00/lib/ghc-4.00
-L/usr/local/ghc-4.00/lib/ghc-4.00
-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3 -L/usr/ccs/bin
-L/usr/ccs/lib -L/usr/local/lib Trc.o -lHSmisc -lHSmisc_cbits -lnsl -lsocket
-lHSexts -lHSmisc -lHSmisc_cbits -lnsl -lsocket -lHSexts -lHS -lHS_cbits -lHSrts
-lgmp -lm -lgcc -lc -lgcc
/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crtend.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/crtn.o
ld: Software Generation Utilities (SGU) SunOS/ELF (LK-2.0 (S/I) - versioning)
Undefined first referenced
symbol in file
IOExts_trace_closureTrc.o
ld: fatal: Symbol referencing errors. No output written to a.out
real0.6
user0.4
sys 0.1
deleting... a.out
rm -f /tmp/ghc25004*
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.
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.
Installation oddity...
Ghc builds and sinstalls smoother than other, apart from one _leetle_ glitch, which still requires (minimal) manual intervention: ln -s ghc-3.02 /usr/local/bin/ghc ln: cannot create /usr/local/bin/ghc: File exists gnumake[2]: *** [install] Error 2 gnumake[1]: *** [install] Error 1 gnumake: *** [install] Error 1 Wouldn't it be a little neater for the installation script to relink or remove the "old" ghc, at least in the case that it really is just a symbolic link? Slainte, Alex.
Re: mkdependHS-?.??
Hi Simon: What's wrong with using 'ghc-3.02 -M' for dependencies I didn't think of it, that's what. ;-) and 'ghc-2.01' for compiling, if you really want to keep 2.10 around? I don't, and as soon as I convince everyone else around here of the same... I don't think the above combination works, though -- changes to things like syslibs will flummox the different version when it tries to read interface files to create the deps. But ghc-2.10 -M ought to work, AFAIK... You could argue that mkdependHS should go in the lib directory, since there's no need to call it directly anymore. I'd buy that. OK, I'll argue that, then. ;-) Slainte, Alex.
Improbable cause.
Not a bug, but not really ghc-users fare either (I think). I realise this is "damned if you do, otherwise, damned", but the following error message confused me: Intervals.hs:207: Type signature doesn't match inferred type Signature: Limit n - Limit n Inferred : Limit Bool - Limit Bool When checking the type signature for `exp' Probable cause: the right hand side of `exp' mentions a top-level variable subject to the dreaded monomorphism restriction The confusion being that the DMR (boo, hiss, abolish in 1.5, doubly abolish in 2.0!) is _not_ applied here. Perhaps one could have a check to see if this is the case before issuing this advice? Slainte, Alex.
Re: Installation oddity...
Sigbjorn Finne replies to me: Wouldn't it be a little neater for the installation script to relink or remove the "old" ghc, at least in the case that it really is just a symbolic link? (I'm assuming you're talking about binary distributions, since the "install" Makefile rules in the source distributions should already do this.) Sorry, I should have been more specific. I did mean a 3.02 build from source... (I didn't think there was a binary distrib...) BTW, I obtained the above from doing a 'gnumake install' immediately after a 'gnumake all'; ought I have done a 'gnumake bin-dist' first? Slainte, Alex.
Installation oddity...
This is a re-send, apologies if it turns up twice. Ghc builds and sinstalls smoother than other, apart from one _leetle_ glitch, which still requires (minimal) manual intervention: ln -s ghc-3.02 /usr/local/bin/ghc ln: cannot create /usr/local/bin/ghc: File exists gnumake[2]: *** [install] Error 2 gnumake[1]: *** [install] Error 1 gnumake: *** [install] Error 1 Wouldn't it be a little neater for the installation script to relink or remove the "old" ghc, at least in the case that it really is just a symbolic link? Slainte, Alex.
Re: Non-standard ghc-3.01 builds.
Sigbjorn: -himap=./%.mc_hi:/usr/local/ghc-3.01/lib/imports/conc/%.mc_hi:/usr/local/ghc-3.0 1/lib/imports/conc/%.mc_hi:/usr/local/ghc-3.01/lib/imports/exts/%.mc_hi:/usr/loc al/ghc-3.01/lib/imports/conc/%.mc_hi:/usr/local/ghc-3.01/lib/imports/exts/%.mc_h i:/usr/local/ghc-3.01/lib/imports/std/%.mc_hi -v -hifile=/tmp/ghc28058.hi -C=/tmp/ghc28058.hc +RTS -H600 -K100 -s/tmp/ghc28058.stat Glasgow Haskell Compiler, version 3.01, for Haskell 1.4 Addr.lhs:8: Could not find valid interface file `Prelude' Addr.lhs:10: Could not find valid interface file `PrelAddr' Looks like the driver script you're using contains absolute paths to the 3.01 installation directory, not relative path names to build tree directories. I'm guessing you've run 'make install' sometime earlier from within this build tree Oops, yes, I have. Sorry if I wasn't explicit about this in my first message. - try re-making the contents of ghc/driver (i.e., 'make clean all'), and see if that helps. Indeed it do, indeed it do. Build still it progress, but it's advanced past that point, at least. Thanks for the usual prompt and thorough servicing. ;-) Slainte, Alex.
Non-standard ghc-3.01 builds.
Hi there. Trying to rebuild 3.01 with some additional "ways", and it falls over at the following point: oconnor.ucc.ie:~/ghc-3.01/build/ghc/lib/exts: gnumake all ===fptools== Recursively making `all' for ways: p mc mr mp ... PWD = /export/home/ferguson/ghc-3.01/build/ghc/lib/exts ==fptools== gnumake way=p all; PWD = /export/home/ferguson/ghc-3.01/build/ghc/lib/exts ==fptools== gnumake way=mc all; PWD = /export/home/ferguson/ghc-3.01/build/ghc/lib/exts rm -f Addr.mc_o ; if [ ! -d Addr ]; then mkdir Addr; else find Addr -name '*.mc_o' -print | xargs rm -f __rm_food ; fi ; ../../../ghc/driver/ghc -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O -split-objs -odir Addr -hisuf mc_hi -concurrent -c Addr.lhs -o Addr.mc_o -osuf mc_o Addr.lhs:8: Could not find valid interface file `Prelude' Addr.lhs:10: Could not find valid interface file `PrelAddr' Compilation had errors gnumake[1]: *** [Addr.mc_o] Error 1 gnumake: *** [all] Error 2 Not clear what's going on here, as the Prelude.mc_hi, etc files were successfully built, and I didn't have this problem with the original build, with only "normal" and "p" ways. What obvious fumble have I made this time? Slainte, Alex.
Re: can't install ghc-2.10
From [EMAIL PROTECTED] Fri Feb 27 04:36:53 1998 Resent-Message-Id: [EMAIL PROTECTED] Old-Received: from mail1.realtime.net by vanuata with SMTP (MMTA); Fri, 27 Feb 1998 04:35:57 + Old-Received: (qmail 29032 invoked from network); 27 Feb 1998 04:35:47 - Old-Received: from zoom.realtime.net (HELO zoom.bga.com) ([EMAIL PROTECTED]) by mail1.realtime.net with SMTP; 27 Feb 1998 04:35:47 - Old-Received: from [204.96.0.211] (apm7-211.realtime.net [204.96.0.211]) by zoom.bga.com (8.6.12/8.6.12) with ESMTP id WAA24114 for [EMAIL PROTECTED]; Thu, 26 Feb 1998 22:35:41 -0600 X-Sender: [EMAIL PROTECTED] (Unverified) Arthur Gold: What _seems_ to be happening is that since PACKAGE_SH_SCRIPTS = nothing, the make dies on syntax...in [config-pkgs] ...(no 'make' maven I...) Me neither! There was a More Elegant Hack posted a while back (if you'll pardon the oxymoron) -- but what worked for me was the crude-but-effective ploy of deleting the offending couple of lines. (The one the error points to and the next, IIRC.) Hope this helps. Slainte, Alex.
Another 3.01 glitchlet.
Hi all. My prior whines about version-numbered binaries have been answered, I see: thanks, esp. to Simon M. However, I have yet another in this series of moans... When I do a gnumake install from the source tree, it flumps, with: ln -s ghc-3.01 /usr/local/bin/ghc ln: cannot create /usr/local/bin/ghc: File exists gnumake[2]: *** [install] Error 2 gnumake[1]: *** [install] Error 2 gnumake: *** [install] Error 2 Removing the old link fixes this behaviour, but ideally it should be automatic, I'd think. And yes, I know I said I'd do it the "proper" way this time, installing from a binary-dist build, but alas, it turns out that needs autoconf, which isn't on the machine I'm building on. So I've reverted to type. ;-) Slainte, Alex.
3.01: readline build glitch?
Is this an Actual Bug, or a Ferguson Foulup? Looks like it's looking for readline stuff that isn't there, and which it _knows_ isn't there. Do I need to disable Readline as a config option? This all worked swimmingly in ghc-3.00... Slainte. Alex. _ oconnor.ucc.ie:~/ghc-3.01/build: configure --prefix=/usr/local/ghc-3.01 --bindir=/usr/local/bin loading cache ./config.cache [spam] checking for readline/readline.h... (cached) no ... oconnor.ucc.ie:~/ghc-3.01/build: gnumake all [lots of spam] ==fptools== gnumake all --no-print-directory -r; in /export/home/ferguson/ghc-3.01/build/ghc/lib/misc rm -f Readline.o ; if [ ! -d Readline ]; then mkdir Readline; else find Readline -name '*.o' -print | xargs rm -f __rm_food ; fi ; ../../../ghc/driver/ghc -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O -split-objs -odir Readline-c Readline.lhs -o Readline.o -osuf o ghc: 189880524 bytes, 120 GCs, 1429062/1558896 avg/max bytes residency (6 samples), 0.00 INIT (0.02 elapsed), 10.32 MUT (22.48 elapsed), 4.00 GC (4.21 elapsed) :ghc ghc: module version unchanged at 1 /tmp/ghc28763.hc:29: `rl_point' undeclared (first use this function) /tmp/ghc28763.hc:29: (Each undeclared identifier is reported only once /tmp/ghc28763.hc:29: for each function it appears in.) /tmp/ghc28763.hc:80: `rl_end' undeclared (first use this function) /tmp/ghc28763.hc:169: `rl_readline_name' undeclared (first use this function) /tmp/ghc28763.hc:445: `rl_end' undeclared (first use this function) /tmp/ghc28763.hc:528: `rl_point' undeclared (first use this function) /tmp/ghc28763.hc:601: `rl_line_buffer' undeclared (first use this function) /tmp/ghc28763.hc:1854: `rl_readline_name' undeclared (first use this function) /tmp/ghc28763.hc:1991: `rl_terminal_name' undeclared (first use this function) /tmp/ghc28763.hc:2128: `rl_readline_name' undeclared (first use this function) /tmp/ghc28763.hc:2265: `rl_line_buffer' undeclared (first use this function) /tmp/ghc28763.hc:3479: warning: assignment makes pointer from integer without a cast gnumake[3]: *** [Readline.o] Error 1 gnumake[2]: *** [all] Error 2 gnumake[1]: *** [all] Error 2 gnumake: *** [all] Error 2 oconnor.ucc.ie:~/ghc-3.01/build:
Wherefore art thou, gcc?
The configure for ghc does the following: checking how to run the C preprocessor... (cached) gcc -E checking how to invoke GNU cpp directly... (cached) /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/cpp Why the latter? And does it only look in the gcc installation for cpp, or does it check ones PATH, or whatever, too? I ask because this leads to an endemic installation glitch here, when I then try to install the same build on several different machines, each of which have different versions of gcc (!), and it all goes horribly wrong when mkdependHS is run, which uses this mechanism for invoking cpp. Not a biggie, obviously (I just patch it up by hand), but a slightly persistant niggle. (And yes, I do know that's not what "wherefore" really means. ;-) ) Slainte, Alex.
NGC bug (?), canonicalised.
SOF:
install-sh is the fallback script used if the configure script is
unable to find an OK looking `install' somewhere along your PATH.
Oops, I confess to not knowing this. Configure doesn't seem to moan too
loudly about the lack of an "install", so I assumed that it was The
Real Program.
Getting back to the first problem I reported, the code-gen crunch:
here's as simple an instance as ever I can possibly construct:
module R where
data NumVal = RealNum Float
isZero (RealNum 0.0) = True
This is the Sun NCG, of course. Doesn't happen without the constructor,
or with Int's, or with -fvia-C...
Slainte,
Alex.
--
ghc-3.00 -c R.hs -H30m -K2M -recomp -fglasgow-exts -cpp -syslib ghc
-syslib hbc -Rgc-stats -dshow-passes -fmax-simplifier-iterations4
-funfolding-use-threshold-0
*** Reader:
*** Renamer:
*** TypeCheck:
*** DeSugar:
*** Core2Core:
*** Core2Core: Simplify
*** Core2Stg:
*** Stg2Stg:
*** CodeGen:
*** CodeOutput:
ghc-3.00: module version changed to 6; reason: usages changed
/usr/ccs/bin/as: "/tmp/ghc24667.s", line 188: error: statement syntax
make: *** [R.o] Error 1
swift.ucc.ie:~/filt4: make R.o OPT=-v
ghc-3.00 -c R.hs -H30m -K2M -recomp -fglasgow-exts -cpp -syslib ghc
-syslib hbc -Rgc-stats -dshow-passes -fmax-simplifier-iterations4
-funfolding-use-threshold-0 -v
The Glorious Glasgow Haskell Compilation System, version 3.00, patchlevel 0
Effective command line: -c -H30m -K2M -recomp -fglasgow-exts -cpp -syslib ghc
-syslib hbc -Rgc-stats -dshow-passes -fmax-simplifier-iterations4
-funfolding-use-threshold-0 -v
Haskellised C pre-processor:
echo '{-# LINE 1 "R.hs" -}' /tmp/ghc24692.cpp
/usr/local/ghc-3.00/lib/hscpp -v -D__HASKELL1__=4 -D__GLASGOW_HASKELL__=300
-I. -I/usr/local/ghc-3.00/lib/includes -I/usr/local/ghc-3.00/lib/includes R.hs
/tmp/ghc24692.cpp
real0.0
user0.0
sys 0.0
hscpp:CPP invoked: /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/cpp
-traditional -D__HASKELL1__=4 -D__GLASGOW_HASKELL__=300 -I.
-I/usr/local/ghc-3.00/lib/includes -I/usr/local/ghc-3.00/lib/includes R.hs
ghc-3.00:compile:Output file R.o doesn't exist
ghc-3.00:recompile:Input file R.hs newer than R.o
Haskell compiler:
/usr/local/ghc-3.00/lib/hsc ,-N ,-W ,/tmp/ghc24692.cpp -fglasgow-exts
-dshow-passes -fignore-interface-pragmas -fomit-interface-pragmas -fsimplify [
-ffloat-lets-exposing-whnf -ffloat-primops-ok -fcase-of-case -fdo-case-elim
-freuse-con -fpedantic-bottoms -funfolding-use-threshold-0
-fmax-simplifier-iterations4 ] -fwarn-overlapping-patterns
-fwarn-missing-methods -fwarn-duplicate-exports
-himap=.%.hi:/usr/local/ghc-3.00/lib/hslibs/hbc/imports%.hi:/usr/local/ghc-3.00/
lib/hslibs/ghc/imports%.hi:/usr/local/ghc-3.00/lib/hslibs/hbc/imports%.hi:/usr/l
ocal/ghc-3.00/lib/hslibs/ghc/imports%.hi:/usr/local/ghc-3.00/lib/imports%.hi
-v -hifile=/tmp/ghc24692.hi -S=/tmp/ghc24692.s +RTS -H3000 -K200
-SR.stat
Glasgow Haskell Compiler, version 3.00, for Haskell 1.4
*** Reader:
*** Renamer:
*** TypeCheck:
*** DeSugar:
*** Core2Core:
*** Core2Core: Simplify
*** Core2Stg:
*** Stg2Stg:
*** CodeGen:
*** CodeOutput:
real3.8
user3.3
sys 0.3
Pin on Haskell consistency info:
echo '
.text
hsc.R.hs.33.0..:' /tmp/ghc24692.s
real0.0
user0.0
sys 0.0
*** New hi file follows...
{-# GHC_PRAGMA INTERFACE VERSION 20 #-}
_interface_ R
_instance_modules_
Addr ArrBase CCall Foreign IO PrelBounded PrelNum
_usages_
PrelBase 1 :: $d1 1 $d10 1 $d11 1 $d12 1 $d13 1 $d15 1 $d2 1 $d20 1 $d21 1 $d24
1 $d25 1 $d26 1 $d27 1 $d28 1 $d29 1 $d3 1 $d30 1 $d31 1 $d32 1 $d33 1 $d34 1
$d36 1 $d37 1 $d38 1 $d39 1 $d4 1 $d40 1 $d41 1 $d42 1 $d43 1 $d5 1 $d6 1 $d7 1
$d8 1 $d9 1 $m- 1 $m/= 1 $m 1 $m= 1 $m 1 $m= 1 $mcompare 1 $menumFromThenTo
1 $menumFromTo 1 $mfromInt 1 $mmax 1 $mmin 1 $mshowList 1 Enum 1 Eq 1 Eval 1 Num
1 Ord 1 Ordering 1 Show 1 String 1;
PrelNum 1 :: $d1 1 $d10 1 $d14 1 $d15 1 $d16 1 $d17 1 $d18 1 $d19 1 $d2 1 $d23 1
$d24 1 $d25 1 $d26 1 $d27 1 $d29 1 $d30 1 $d31 1 $d32 1 $d33 1 $d34 1 $d35 1
$d36 1 $d37 1 $d38 1 $d39 1 $d4 1 $d5 1 $d6 1 $d7 1 $d8 1 $d9 1 $mdiv 1 $mdivMod
1 $mmod 1 $mquot 1 $mrecip 1 $mrem 1 Fractional 1 Integral 1 Ratio 1 Rational 1
Real 1;
PrelTup 1 :: $d13 1 $d4 1 $d49 1 $d9 1;
_exports_
R isZero NumVal(RealNum);
_instances_
instance {PrelBase.Eval NumVal} = $d1;
_declarations_
data NumVal = RealNum PrelBase.Float ;
$d1 _:_ {PrelBase.Eval NumVal} ;;
isZero _:_ NumVal - PrelBase.Bool ;;
ghc-3.00: module version unchanged at 6
Replace .hi file, if changed:
cmp -s R.hi /tmp/ghc24692.hi-new || ( rm -f R.hi cp
/tmp/ghc24692.hi-new R.hi )
real0.0
user0.0
sys 0.0
Unix assembler:
gcc -o R.o -c /tmp/ghc24692.s
/usr/ccs/bin/as: "/tmp/ghc24692.s", line 188: error: statement syntax
real0.0
user0.0
sys 0.0
deleting... /tmp/ghc24692.cpp /tmp/ghc24692.hi /tmp/ghc24692.s R.stat R.o
rm
Re: errors in installing GHC2.10 in iris machine
Tina Yu: /bin/sh: Syntax error at line 1: `;' unexpected make[1]: *** [config-pkgs] Error 2 make[1]: Leaving directory `/tmp_mnt/cs/research/isrg/croissant/etg/var/src/ghc-2.10/fptools' make: *** [in-place] Error 2 I ran into this one too! It's a shell problem -- or depending how you look at it, a shell syntax error. ;-) It's documented (and fixed, sorta) in: http://www.dcs.gla.ac.uk/fp/software/ghc/known-bugs.html Slainte, Alex.
That's ghc-3.00, please!
Hi again. I note in passing that ghc still installs itself as "ghc", not as "ghc-[version]" (with ghc as a link). At least two of the Si*o*n-Squad -- that was a regular expression, not an expletive deleted ;-) -- have been promising that this will be/has been fixed in the next version for several versions now! Mind you, that (last three nits aside), ghc-3.00 has become so easy to install these days that we Haskell Gurus might be out of a job if it wasn't for having to have someone to adjust the links by hand. ;-) Slainte, Alex.
error: (misc)
install-sh does a fine line in unhelpful error messages: well, error message singular, at any rate... for i in hp2ps; do \ /export/home/ferguson/ghc-3.00/build/install-sh -c -g ghc-admin -s $i /usr/local/bin; \ done hp2ps:error reading file This seems to be its catch-all for anything that goes wrong, making diagnosis a tad tricky. On one machine it was a full disk, another one I'm still trying to puzzle out... Cheers, Alex.
Crunch!
New feature of ghc-3.00 under Solaris 2.5: a broken native code generator? duck! -fvia-C makes the above go away. Will canonicalise and report back after I finish fighting some other fires... Slainte, Alex. -- ghc-3.00 -c RTE.hs -H30m -K2M -recomp -fglasgow-exts -cpp -syslib ghc -syslib hbc -Rgc-stats -dshow-passes -fmax-simplifier-iterations4 -funfolding-use-threshold-0 *** Reader: "RTE.hs":360: _scc_ (`set [profiling] cost centre') ignored "RTE.hs":362: _scc_ (`set [profiling] cost centre') ignored "RTE.hs":364: _scc_ (`set [profiling] cost centre') ignored "RTE.hs":366: _scc_ (`set [profiling] cost centre') ignored "RTE.hs":374: _scc_ (`set [profiling] cost centre') ignored "RTE.hs":378: _scc_ (`set [profiling] cost centre') ignored "RTE.hs":382: _scc_ (`set [profiling] cost centre') ignored "RTE.hs":384: _scc_ (`set [profiling] cost centre') ignored "RTE.hs":387: _scc_ (`set [profiling] cost centre') ignored "RTE.hs":388: _scc_ (`set [profiling] cost centre') ignored "RTE.hs":395: _scc_ (`set [profiling] cost centre') ignored "RTE.hs":399: _scc_ (`set [profiling] cost centre') ignored "RTE.hs":401: _scc_ (`set [profiling] cost centre') ignored "RTE.hs":403: _scc_ (`set [profiling] cost centre') ignored "RTE.hs":410: _scc_ (`set [profiling] cost centre') ignored *** Renamer: *** TypeCheck: *** DeSugar: RTE.hs:522: Pattern match(es) are overlapped in the definition of function `anyOp' t fn (i1@(InterVal _)) (Set [n2]) = ... t fn (Set [v1]) (i2@(InterVal _)) = ... RTE.hs:732: Pattern match(es) are overlapped in the definition of function `rplacEachEnt' f e = ... *** Core2Core: *** Core2Core: Simplify *** Core2Stg: *** Stg2Stg: *** CodeGen: *** CodeOutput: ghc-3.00: module version unchanged at 2 /usr/ccs/bin/as: "/tmp/ghc12694.s", line 4274: error: statement syntax
Profiling, again.
Another non-killing, but rather annoying error message: this one is provoked by duplicate _scc_ labels. I don't see the sense in this restriction, myself, but at any rate this wouldn't seem to be the handiest way of detecting same... Cheers, Alex. -- ghc-2.09 -c Intervals.hs -H30m -K2M -recomp -fglasgow-exts -cpp -syslib ghc -syslib hbc -Rgc-stats -dshow-passes -fmax-simplifier-iterations4 -funfolding-use-threshold-0 -prof -auto-all *** Reader: *** Renamer: *** TypeCheck: *** DeSugar: *** Core2Core: *** Core2Core: Simplify *** Core2Stg: *** Stg2Stg: *** CodeGen: *** CodeOutput: Module version unchanged at 1 /tmp/ghc13193.hc:105: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:104: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:105: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:104: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:106: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:105: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:106: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:105: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:107: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:106: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:107: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:106: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:108: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:107: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:108: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:107: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:109: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:108: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:109: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:108: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:110: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:109: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:110: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:109: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:111: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:110: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:111: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:110: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:112: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:111: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:112: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:111: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:113: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:112: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:113: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:112: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:114: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:113: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:114: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:113: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:115: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:114: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:115: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:114: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:116: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:115: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:116: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:115: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:117: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:116: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:117: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:116: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:118: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:117: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:118: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:117: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:119: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:118: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:119: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:118: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:120: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:119: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:120: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:119: `CC_IntervalsZdZp' previously defined here /tmp/ghc13193.hc:121: redefinition of `CC_IntervalsZdZp_struct' /tmp/ghc13193.hc:120: `CC_IntervalsZdZp_struct' previously defined here /tmp/ghc13193.hc:121: redefinition of `CC_IntervalsZdZp' /tmp/ghc13193.hc:120: `CC_IntervalsZdZp'
^C
Hi there. Peering at the Posix stuff on process handling, I wrote the following program: import Posix main = do installHandler sigINT Ignore Nothing loop loop = do putStr "" loop This ought to loop forever (yup), ignoring any SIG_INT's (nup). Is the above fundamentally misconceived in some hideous way that I have failed to spot? Blocking and catching seem to work fine and as I'd expect, but I don't see how to get much useful functionality from just those two, if Ignore can't be persuaded to work. Is this a bug in the posix lib, or is my admittedly sketchy notion of handling Unix interrupts letting me down? Slainte, Alex.
Re: 2.09 binary for Alpha/Digital UNIX
Byron Cook: does anyone have binary distribution of ghc-2.09 for the Alpha/Digital UNIX? I'm trying to help someone else via email, he's having a bad ghc experience. I have a build of 2.0_8_ on an Alpha, but no 2.09 currently. It went fairly smoothly for me, though, so I'm help to help field questions... Cheers, Alex.
Re: Another minor mystery...
bowen.ucc.ie:~/filter: galileo -dE Fail: You tried to evaluate voidbowen.ucc.ie:~/filter: This error decided to go away, pretty much of its own accord. Maybe caused by an out of date (2.07) .o lying around someplace, or some such... Cheers, Alex.
Re: installing haskell from source
From [EMAIL PROTECTED] Thu Dec 4 01:29:20 1997 Resent-Message-Id: [EMAIL PROTECTED] Old-Received: from optima.cs.arizona.edu by vanuata with SMTP (MMTA) with ESMTP; Thu, 4 Dec 1997 01:27:09 + Old-Received: from baskerville.CS.Arizona.EDU (baskerville.CS.Arizona.EDU [192.12.69.35]) by optima.cs.arizona.edu (8.8.7/8.8.7) with ESMTP id SAA14316for [EMAIL PROTECTED]; Wed, 3 Dec 1997 18:26:42 -0700 (MST) Old-Received: from localhost (muth@localhost) by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id SAA00072 for [EMAIL PROTECTED]; Wed, 3 Dec 1997 18:26:40 -0700 (MST) X-Authentication-Warning: baskerville.CS.Arizona.EDU: muth owned process doing -bs Date: Wed, 3 Dec 1997 18:26:40 -0700 (MST) Hi Robert. This isn't expert advice, but it might be the best you get at this time of night... ;-) sh: /home/muth/PACKAGES/fptools/ghc/driver/../compiler/hsc: not found This is a pretty generic one; the Actual Compiler (TM) has failed to build, but gnumake has plowed on regardless, obtaining the above error message as soon as it tries to run the (non-existant) Haskell compiler. You'll need to backscroll somewhat further through the spam, and see what caused the compiler build to fail. Or equally, cd to ghc/compiler, and gmake all again. Other such classics are "can't find interface (.hi) file for module "FastString", and stuff about failing to build AdamsBashforth, etc., each kilometers of spam away from the actual error... ;-) (Respectively, gmake boot failure, and gmake compiler error). Is it possible to tweak the Makefiles to have them halt closer to the original offender, crack ghc team? Hope this helps, Alex.
Re: Mysterious 2.09 message.
Sigbjorn: This sounds plausible, if the above msg had printed out the Id including its module qualifier, it would have been a little bit easier to debug this (Maybe moved from PrelBase to PrelMaybe with 2.09.) Well actually, what would have been more helpful is knowing which interface file it was that was causing the problem. Doubtless there's a way of having this stuff spewed out, but shouldn't it be automatic, for interface file errors? Another case where leaving out module qualifiers on Ids in warnings/errors, does more harm than good. This probably should be controllable from the command line. ... And in the other case, wouldn't the better fix be to put in a test to see if module qualifiers are required to distinquish the entities in the error message? Anyway, I recompiled some things, and the problem went away, so I think it was indeed an interface file problem. Cheers, Alex.
Another minor mystery...
Just run into the following in 2.09, didn't seem to happen with 2.07. bowen.ucc.ie:~/filter: galileo -dE Fail: You tried to evaluate voidbowen.ucc.ie:~/filter: Seems to correspond to doing case analysis on a non-empty getArgs. Any ideas? Cheers, Alex.
Re: Problem with assembler on Digital UNIX
Hi, Alex. Your problem sounds not entirely dissimiliar to one I encountered with ghc-2.08 on Digital UNIX V4.0B, though I'm not sure it's exactly the same -- see ghc-bugs, _passim_. ;-) Anyway, we are now trying to compile the GHC with -fvia-C. That's what worked for me. In fact, I only had to compile one module by this route (the one producing the as error...), the rest went fine. Good luck, Alex.
Re: bug report
Did you do 'make install' in ghc, instead of using the binary distribution? I did make install from a build from source, yes, not least as there was no binary distrib. available at that point. ;-) Hard links are a pain for several reasons - if you install a new ghc over the existing one, you have to be sure to remove the old one first, or you might stomp on the ghc-2.09 link too... Having created such links by hand, I can report that the install script doesn't appear to thusly stomp. I guess it'd do so if it changed the file contents, rather than the handle, but don't quote me on the details of this, as I haven't investigated the details of what the script does... Either hard or symbolic is fine by me, mind you. Cheers, Alex.
Re: ANNOUNCE: The Glasgow Haskell Compiler, Version 2.09
Well, works for me on sparc-solaris2, anyhow (after hacking around each of the above snafus). Parthian shot complaint, though: the install script _still_ doesn't install a ghc-version link to the driver, which was acclaimed as a jolly good idea and promised for future releases any number of versions ago... (GHC makefiles are way too obfuscated for me to hack by hand, so I resort to doing N links, manually.) Otherwise, jolly well done. ;-) Cheers, Alex.
Re: Bizarre Secretions in 2.09
Hi all. More configuration irritations... I ran configure on a machine with version 3.7.2.3 of gcc, then later tried to make on a different machine, with only version 3.7.2. Oops, that's 2.7.2, of course. (C compilers from the future...) To answer my own question, apparently said paths were hidden in the likes of the built scripts for mkdependHS, mkdependC, and hscpp. Rest of build seems to be proceeding OK, thrashing it's way through the libraries even as I speak... Alex.
Re: bug report
From [EMAIL PROTECTED] Fri Nov 28 11:48:59 1997 This is another file missing from the source distribution. The new one is now up, and it contains all the necessary files. Can you put this up as a patch, too? It does for me - but the sense of the link is reversed (i.e. now ghc points to ghc-2.09, which is the real driver). Odd. It doesn't seem to do this at all for me. There's no "ghc-2.09", and "ghc" isn't a link. I can't see where in the makefile this should be happening, either, but as I said, ah dinnae ken GHC makefiles... This is so that you can install the new version over the older version. Why not make it a "hard" link, in the same directory, thereby making the point of which one is the real one moot? Cheers, Alex.
Re: ANNOUNCE: The Glasgow Haskell Compiler, Version 2.09
Simon M: We have a new set of Web pages at http://www.dcs.gla.ac.uk/fp/software/ghc/, there will probably be a few glitches for a while so bear with us. Binaries: I've made binaries for [...] sparc-sun-solaris2. Here's one for starters... The above binary archive file seems not to exist. (I checked the directory to see if if was a typo in the link, apparently not.) Slainte, Alex.
Bizarre Secretions in 2.09
Hi all. More configuration irritations... I ran configure on a machine with version 3.7.2.3 of gcc, then later tried to make on a different machine, with only version 3.7.2. It crunched looking for cpp in the wrong place, unsurprising. However, even after deleting config.cache, rerunning configure, and then re-doing gnumake boot, it _still_ insisted on looking for cpp in the wrong place. Where is it hiding this gcc version information so furtively and tenaciously? Alex.
GHC-2.08 on alpha, for a change...
Haven't properly investigated this myself yet, but just in case this looks familiar to anyone, I get the following, trying to build 2.08 on an alpha, with ghc-0.29. Unix assembler: gcc -o absCSyn/PprAbsC.o -c /usr/tmp/ghc10102.s as1: Internal: /usr/tmp/ghc10102.s, line 32: ../../../../../../src/usr/ccs/bin/as/as1util.p, line 460: idn sym_tab.alloc_len Fatal error in: /usr/lib/cmplrs/cc/as1 Segmentation fault real 1.8 user 1.1 sys0.1 deleting... absCSyn/PprAbsC.o rm -f /usr/tmp/ghc10102* gmake: *** [absCSyn/PprAbsC.o] Error 1 An internal assembler error? Pretty impressive, I felt. ;-) -fvia-C seems to work to hack around it (fingers crossed)... Cheers, Alex.
HP (ab)users of the world unite...
Hi all. Has anyone else had problems building one-or-other version of ghc-2.0[5678] on the HPPA with ghc-0.29, and the HP linker? And if so, have you found a workaround, either by a ghc tweak or by using a different linker? I've been thrashing around in a number of such avenues, so far without success. Cheers, Alex.
Fixed in 2.08?
swift.ucc.ie:~/filter: cat cwd.hs import Directory main = getCurrentDirectory return () swift.ucc.ie:~/filter: ghc-2.05 cwd.hs Module version unchanged at 1 swift.ucc.ie:~/filter: a.out swift.ucc.ie:~/filter: ghc-2.07 cwd.hs Module version unchanged at 1 swift.ucc.ie:~/filter: a.out Segmentation fault caught, address = Abort
Re: Building ghc-2.05 on an HP (or not).
We don't have direct access to any HPs here at Glasgow right now, but I recall running into this way back with 2.02. Hrm. 2.02 built fine for me, though. In fact, 2.07 actually _built_: and then crashed, as per Sven's experiences. I'll look into your suggestion, tomorrow... when I'm sober. ;-) We can prolly cope with our existing setup for the time being, though... unless The Boss abruptly mandates otherwise. Csheersh, Alex.
Building ghc-2.05 on an HP (or not).
Hi all. Since compiling ghc-2.0[678] on an HP with 0.29 seems to be terminally broken (see ghc-bugs, _passim_), I'm trying to build 2.0_5_ by that route, as seems to have worked for Sven. Alas: not for me: it gets as far as the final link for hsc, (spam deleted), and then says: collect2: ld terminated with signal 11 , core dumped /bin/ld: (Warning) Inter-quadrant branch in simplCore/OccurAnal.o Anyone know: a) what the heck that means; and/or b) how to fix? Alternatively, I'll settle for c): any (other) feasible way of obtaining a working ghc-2.0[5-8] on our HP. Cheers, Alex.
-recomp
Has anyone noticed anything flakey about the 2.07 recompilation system? I've noticed several unnecessary-looking version changes and the like since switching over. Any chance it might be confused by hi's left around from version version (2.05), or some such? Sorry to be so vague, but I fear this one would be nigh-impossible to reproduce reliably. Cheers, Alex.
Re: -recomp
Further to my previous message: What it looks like is that I have a cycle of module deps, and whenever any of them are changed, -recomp gets very confused and recompiles them all. This seems to be because each of them becomes a new version because its usages because its predecessor in the chain's version changed, because its usages did... This is a Real Pain. Anyone else been stung by this? BTW, did there use to be/is there still an option to tell -recomp to be explicit about why it had to do a recompilation? I found -hi-diffs-with-usages, which was of some help, but I thought there was a more directly useful one too, but I couldn't lay my hands on it. Cyclically, Alex.
ghc-2.07 on HPUX calamaties.
Anyone got any bright ideas on this on? hsc seems to build OK on a
HPUX box, but as soon as it tries to compile PrelBase:
wilde.ucc.ie:~/ghc-2.07/fptools/ghc/lib: ../driver/ghc -H20M -cpp -fglasgow-exts
-fvia-C -Rghc-timing -c ghc/PrelBase.lhs -dshow-passes
-fmax-simplifier-iterations4 -funfolding-use-threshold-0
-fshow-simplifier-progress
Warning: GENERATE_SPECS pre-processing pragma ignored:
{-# GENERATE_SPECS subtract
a{Int#,Double#,Int,Double,Complex(Double#),Complex(Double)} #-}
Warning: GENERATE_SPECS pre-processing pragma ignored:
{-# GENERATE_SPECS (.) a b c #-}
Warning: GENERATE_SPECS pre-processing pragma ignored:
{-# GENERATE_SPECS data a :: Lift a #-}
Warning: GENERATE_SPECS pre-processing pragma ignored:
{-# GENERATE_SPECS showList__ a #-}
*** Reader:
*** Renamer:
*** TypeCheck:
*** DeSugar:
*** Core2Core:
*** Core2Core: Simplify
sh: 16173 Memory fault(coredump)
wilde.ucc.ie:~/ghc-2.07/fptools/ghc/lib:
Slightly re-jigged invocation re-run by hand for suitably spammy, if
still uniformative, output. Cranking -fmax-simplifier-iterations down
1, or come to that, 0, makes no difference. Despite the message, it
seems that the process id mentioned in the error message is that of
hsc, not the invoking shell.
Retiring hurt,
Alex.
Re: ghc-2.07 and ghc-0.29
Simon M. sez: GHC 2.07 definitely does compile with 0.29, including the happy-related bits. The happy sources in the tree will compile with 0.29, and Happy can be told to generate 0.29-compatible parsers by giving it the -1.2 flag (this flag is used automatically by ghc/compiler/Makefile if it detects that ghc-0.29 is being used). There must be some makefile wrinkle here, then, as apparently the fact that ghc-0.29 was (by default, even) being used wasn't detected, as the Parser.hs being produced was certainly 1.3-ish, and I didn't know how to override that behaviour. Mysterious Flag noted for future reference, though... Thanks to Jon and Juan, too, for their workarounds. Apart from this setback, it compiles perfectly handily, I'm relieved to say... Slainte, Alex.
Re: ghc-2.07 and ghc-0.29
Juan Jose Quintela quotes me quoting Simon... GHC 2.07 definitely does compile with 0.29, including the happy-related bits. The happy sources in the tree will compile with 0.29, and Happy can be told to generate 0.29-compatible parsers by giving it the -1.2 flag (this flag is used automatically by Yes, but the problem is that the Parser.hs that cames with the sources of ghc-2.07 is not ghc-0.29 friendly (it has newtype declarations) and you can't compile another Parser.hs becouse you dont have happy, and so on ... I think it's more subtle than that. I _did_ already have a 1.3-style version of happy, and remaking Parser.hs with it availed me naught. Maybe I flubbed the flags myself when I did it though, I can't recall exactly what sequence I tried to hack my way around by. BTW, I got three copies of the above message, which is (at least ;-) one too many. Is the list playing up again when replies get sent to "[EMAIL PROTECTED]"? Administrivially, Alex.
Re: Happy breaks ghc (again).
To partially answer my own question... Big problems with some output from Happy 1.2-alpha [...] I'm quite keen to get it sorted out and/or worked around. Easiest work-around is not to use "happy -g" output, which I neglected to mention I was using. Evidently some sort of type-checking problem due to unboxed thingies... Slainte, Alex.
Re: Ian Collier: ghc-0.29-sparc-sun-sunos4 won't compile ghc-2.04
Hi again Ian. Look on the bright side: this time the actual compiler got build successfully... Now there's just the small matter of the libraries... [in the middle of a 2.05 build on a SunOS4 box] ==fptools== make way=p all; PWD = /amdtmp_mnt/onyx/packages2/lang/ghc/ghc-2.05-sparc-sun-sunos4/ghc/lib rm -f ghc/ArrBase.p_o ; if [ ! -d ghc/ArrBase ]; then mkdir ghc/ArrBase ; else exit 0; fi; find ghc/ArrBase -name '*.p_o' -print | xargs rm -f __rm_food; ../../ghc/driver/ghc -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -split-o bjs -odir ghc/ArrBase -hisuf p_hi -prof -prof -GPrelude -c ghc/ArrBase.lhs - o ghc/ArrBase.p_o -osuf p_o [snip] ghc/ArrBase.lhs:15: Could not find valid interface file `Ix' ghc/ArrBase.lhs:16: Could not find valid interface file `PrelList' [snip more of the same] Same thing again, I think: just do make for the "missing" targets. gnumake ghc/lib/required/Ix.p_hi etc. If you have to do this too much, though, I'd get very suspicious... I'm suspicious about this one, though. I, and several other people, have reported building 2.05 with no such makefile hiccups. I can't think why this would be a sun-specific phenomemon, either... Conceivably a make-version thing? I see there the flag "-hisuf p_hi" but I haven't got any p_hi files. Surely some mistake? Not yet you don't; that flag is telling it to use that suffix for one of the _output_ files (interface files for profiling build). BTW, if you don't need profiling, it may be worthwhile turning this part of the build off, as that profiled-version libraries are rather large, certainly under Solaris. Responsible for 75% of the size of the complete installation, in fact. (!) Have you any ideas or should I join the mailing list after all?... You probably should... it'd save my cc: line a bit of work. ;-) Cheers, Alex.
Re: Ian Collier: ghc-0.29-sparc-sun-sunos4 won't compile ghc-2.04
Ian Collier gets the notorious: "parser/U_binding.hs", line 6, column 22: can't find interface (.hi) file for module "FastString" on input: "FastString" make: *** [parser/U_binding.o] Error 1 I had something much the same happen; some generic Makefile peccadilo I assume, which is causing it to try to import a module it hasn't compiled yet. I didn't bother trying to fix it the "clean" way, as you can get around it by either: a) intervene "manually", by doing, in the ghc/compiler directory, "make utils/FastString.o", and then re-running the "make all"; I forget if it does the same thing elsewhere, but you can get around it by similar means if it does; or: b) Getting and building ghc-2.05, which compiles from source with nary such a squeak. Hope this helps, Alex.
Tiny 2.05 glitch.
Only one problem with 2.05, so far: while building the compiler, gnumake all seems to just lose interest after simplCore/ConFold.lhs, and then start trying to build the libraries, with predictably little success. Is this just an oddity of our flakey machines, or is there some makefile oddity? In any case, simply restarting the build resumed in the right place, and successfully built hsc, so it's hardly a bear of a bug. Excerpt below... Vigilantly, Alex. -- ghc-0.29 -H50M -cpp -fhaskell-1.3 -fglasgow-exts -DCOMPILING_GHC -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils -ibasicTypes -itypes -ihsSyn -iprelude -irename -itypecheck -ideSugar -icoreSyn -ispecialise -isimplCore -istranal -istgSyn -isimplStg -icodeGen -iabsCSyn -imain -ireader -iprofiling -iparser -inativeGen -fomit-derived-read -fomit-reexported-instances -DOMIT_DEFORESTER -c simplCore/ConFold.lhs -o simplCore/ConFold.o -osuf o ghc: 39206464 bytes, 1 GCs, 0/0 avg/max bytes residency (0 samples), 0.01 INIT (0.01 elapsed), 2.90 MUT (3.88 elapsed), 0.20 GC (0.22 elapsed) :ghc ==fptools== gnumake all; in /export/home/ferguson/ghc-2.05/build/ghc/lib ... etc...
Re: Mysterious DEC utterances.
Sven Panne on: Warning: Linking some objects which contain exception information sections and some which do not. This may cause fatal runtime exception handling problems (last obj encountered without exceptions was main/LoopHack.o). I don't speak DECish too fluently, but here's my humble guess: Under arcane circumstances, linking gcc-compiled code on DEC-Unix 3.2 produces the above warning. It's annoying, but it doesn't hurt (at least apart from aesthetics :-) . I can now concur, as the rest of the build went swimmingly. Perhaps Josh's problems were 3.2 specific... I don't know if 3.2 and 4.0 are alleged to be object code compatible -- if so, and anyone's desparate enough to try, I could perhaps arrange to send them a built hsc. More utterances: I also note the following message from later in said build. I can't recall having seen any such things things before, though perhaps I either didn't do builds on other platforms with -dshow-passes set (or just didn't notice the output if I did). I assume it too is benign, just mildly Mysterious to we mere mortals. Cheers, Alex. -- rm -f src/PosixUtil.p_o ; if [ ! -d src/PosixUtil ]; then mkdir src/PosixUtil ; else exit 0; fi; find src/PosixUtil -name '*.p_o' -print | xargs rm -f __rm_food; ../../ghc/driver/ghc -H50M -K8M -split-objs -odir src/PosixUtil -hisuf p_hi -recomp -isrc -cpp -fvia-C -fglasgow-exts -dcore-lint -prof '-#include"cbits/libposix.h"' -monly-3-regs -dshow-passes -c src/PosixUtil.lhs -o src/PosixUtil.p_o -osuf p_o ghc: WARNING: splitting objects when profiling will *BREAK* if any _scc_s are present! *** Reader: *** Renamer: *** TypeCheck: *** DeSugar: *** Core2Core: *** Core2Core: Simplify *** Core2Stg: *** Stg2Stg: *** Core Lint result of TidyCorePgm *** Core Lint result of Simplify (3) *** CodeGen: ghc: module version changed to 1; reason: no old .hi file
Mysterious DEC utterances.
Just in case the following throws any light on Josh Burdick's build problems on an alpha, I got the following message, when my build here eventually got as far as hsc. I'm using OSF 3.2, however, so your kilometerage may vary considerably... Good luck, Alex. Spam alert: but honest, it's only one command! ghc-0.29 -o hsc -H50M -K8M -cpp -fhaskell-1.3 -fglasgow-exts -DCOMPILING_GHC -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils -ibasicTypes -itypes -ihsSyn -iprelude -irename -itypecheck -ideSugar -icoreSyn -ispecialise -isimplCore -istranal -istgSyn -isimplStg -icodeGen -iabsCSyn -imain -ireader -iprofiling -iparser -inativeGen -fomit-derived-read -fomit-reexported-instances -DOMIT_DEFORESTER -no-link-chkparser/U_binding.o parser/U_constr.o parser/U_either.o parser/U_entidt.o parser/U_list.o parser/U_literal.o parser/U_maybe.o parser/U_pbinding.o parser/U_qid.o parser/U_tree.o parser/U_ttype.o utils/Argv.o utils/Bag.o utils/BitSet.o utils/Digraph.o utils/FastString.o utils/FiniteMap.o utils/ListSetOps.o utils/MatchEnv.o utils/Maybes.o utils/OrdList.o utils/Outputable.o utils/Pretty.o utils/PrimPacked.o utils/SST.o utils/StringBuffer.o utils/UniqFM.o utils/UniqSet.o utils/Util.o basicTypes/BasicTypes.o basicTypes/Demand.o basicTypes/FieldLabel.o basicTypes/Id.o basicTypes/IdInfo.o basicTypes/IdUtils.o basicTypes/Literal.o basicTypes/Name.o basicTypes/PprEnv.o basicTypes/PragmaInfo.o basicTypes/SrcLoc.o basicTypes/UniqSupply.o basicTypes/Unique.o types/Class.o types/Kind.o types/PprType.o types/TyCon.o types/TyVar.o types/Type.o types/Usage.o hsSyn/HsBasic.o hsSyn/HsBinds.o hsSyn/HsCore.o hsSyn/HsDecls.o hsSyn/HsExpr.o hsSyn/HsImpExp.o hsSyn/HsMatches.o hsSyn/HsPat.o hsSyn/HsPragmas.o hsSyn/HsSyn.o hsSyn/HsTypes.o prelude/PrelInfo.o prelude/PrelMods.o prelude/PrelVals.o prelude/PrimOp.o prelude/PrimRep.o prelude/StdIdInfo.o prelude/TysPrim.o prelude/TysWiredIn.o rename/Rename.o rename/RnBinds.o rename/RnEnv.o rename/RnExpr.o rename/RnHsSyn.o rename/RnIfaces.o rename/RnMonad.o rename/RnNames.o rename/RnSource.o typecheck/Inst.o typecheck/TcBinds.o typecheck/TcClassDcl.o typecheck/TcDefaults.o typecheck/TcDeriv.o typecheck/TcEnv.o typecheck/TcExpr.o typecheck/TcGRHSs.o typecheck/TcGenDeriv.o typecheck/TcHsSyn.o typecheck/TcIfaceSig.o typecheck/TcInstDcls.o typecheck/TcInstUtil.o typecheck/TcKind.o typecheck/TcMatches.o typecheck/TcModule.o typecheck/TcMonad.o typecheck/TcMonoType.o typecheck/TcPat.o typecheck/TcSimplify.o typecheck/TcTyClsDecls.o typecheck/TcTyDecls.o typecheck/TcType.o typecheck/Unify.o deSugar/Desugar.o deSugar/DsBinds.o deSugar/DsCCall.o deSugar/DsExpr.o deSugar/DsGRHSs.o deSugar/DsHsSyn.o deSugar/DsListComp.o deSugar/DsMonad.o deSugar/DsUtils.o deSugar/Match.o deSugar/MatchCon.o deSugar/MatchLit.o coreSyn/AnnCoreSyn.o coreSyn/CoreLift.o coreSyn/CoreLint.o coreSyn/CoreSyn.o coreSyn/CoreUnfold.o coreSyn/CoreUtils.o coreSyn/FreeVars.o coreSyn/PprCore.o specialise/SpecEnv.o specialise/SpecUtils.o specialise/Specialise.o simplCore/AnalFBWW.o simplCore/BinderInfo.o simplCore/ConFold.o simplCore/FloatIn.o simplCore/FloatOut.o simplCore/FoldrBuildWW.o simplCore/LiberateCase.o simplCore/MagicUFs.o simplCore/OccurAnal.o simplCore/SAT.o simplCore/SATMonad.o simplCore/SetLevels.o simplCore/SimplCase.o simplCore/SimplCore.o simplCore/SimplEnv.o simplCore/SimplMonad.o simplCore/SimplPgm.o simplCore/SimplUtils.o simplCore/SimplVar.o simplCore/Simplify.o stranal/SaAbsInt.o stranal/SaLib.o stranal/StrictAnal.o stranal/WorkWrap.o stranal/WwLib.o stgSyn/CoreToStg.o stgSyn/StgLint.o stgSyn/StgSyn.o simplStg/LambdaLift.o simplStg/SimplStg.o simplStg/StgStats.o simplStg/StgVarInfo.o simplStg/UpdAnal.o codeGen/CgBindery.o codeGen/CgCase.o codeGen/CgClosure.o codeGen/CgCompInfo.o codeGen/CgCon.o codeGen/CgConTbls.o codeGen/CgExpr.o codeGen/CgHeapery.o codeGen/CgLetNoEscape.o codeGen/CgMonad.o codeGen/CgRetConv.o codeGen/CgStackery.o codeGen/CgTailCall.o codeGen/CgUpdate.o codeGen/CgUsages.o codeGen/ClosureInfo.o codeGen/CodeGen.o codeGen/SMRep.o absCSyn/AbsCSyn.o absCSyn/AbsCUtils.o absCSyn/CLabel.o absCSyn/CStrings.o absCSyn/Costs.o absCSyn/HeapOffs.o absCSyn/PprAbsC.o main/CmdLineOpts.o main/Constants.o main/ErrUtils.o main/Main.o main/MkIface.o reader/Lex.o reader/PrefixSyn.o reader/PrefixToHs.o reader/RdrHsSyn.o reader/ReadPrefix.o profiling/CostCentre.o profiling/SCCfinal.o parser/UgenAll.o parser/UgenUtil.o nativeGen/AbsCStixGen.o nativeGen/AsmCodeGen.o nativeGen/AsmRegAlloc.o nativeGen/MachCode.o nativeGen/MachMisc.o nativeGen/MachRegs.o nativeGen/PprMach.o nativeGen/RegAllocInfo.o nativeGen/Stix.o nativeGen/StixInfo.o nativeGen/StixInteger.o nativeGen/StixMacro.o nativeGen/StixPrim.o rename/ParseIface.o
Re: Command line tribulations.
Neither -optCrts-Sstderr nor -Rgc-stats seem to do anything useful; the file created by the latter contains only a ghc command line, and the former seems to do nothing at all. Hmm..need more details, I'm not able to reproduce this behaviour. Transcript below. Maybe the option is getting "lost" for some reason... In short, apart from what -dshow-passes and -Rgc-stats tell me, I'm pretty in the dark. (I'm guessing you mean -Rghc-timing rather than -Rgc-stats for the above) I did, sorry. Processing the combined output of -dshow-passes and -optCrts-Sstderr to produce what you're suggesting shouldn't be hard - maybe we should add it as an experimental option for people to try? A related extension could be to add timings to the output of -dshow-passes. Yes, either of those would be good. For my purposes, a per-phase -Rghc-timing -like summary would be prefectly adequate, I think. While I'm pretending Wishes were Fishes, though, some way of getting more detailed info on what's going on _within_ the core2core phase would also help, for those "which one of thes Clever Optimisations is sucking up all my heap, and should therefore be brutally switched off" moments. Cheers, Alex. -- swift.ucc.ie:~/filter/tmp2: rm Lexer.o swift.ucc.ie:~/filter/tmp2: make Lexer.o ghc-2.04 -c Lexer.lhs -Rgc-stats -H30m -K2M -recomp -fglasgow-exts -cpp -syslib ghc -H0M -H70M -Rghc-timing -dshow-passes -fmax-simplifier-iterations3 -funfolding-use-threshold-0 ghc-2.04: resetting heap-size to zero!!! 0 ghc-2.04: ignoring heap-size-setting option (-H30m)...not the largest seen ghc-2.04: resetting heap-size to zero!!! 0 *** Reader: *** Renamer: *** TypeCheck: *** DeSugar: Lexer.lhs:119: Warning: Possibly incomplete patterns in the definition of function `lexSym' Lexer.lhs:174: Warning: Possibly incomplete patterns in the definition of function `lexDot' *** Core2Core: *** Core2Core: Simplify *** Core2Stg: *** Stg2Stg: *** CodeGen: ghc: 166984724 bytes, 5 GCs, 0/0 avg/max bytes residency (0 samples), 0.01 INIT (0.03 elapsed), 10.72 MUT (12.20 elapsed), 2.29 GC (2.70 elapsed) :ghc Module version unchanged at 1 swift.ucc.ie:~/filter/tmp2: cat Lexer.stat hsc ,-N ,-W ,/tmp/ghc17244.cpp -fglasgow-exts -dshow-passes -fignore-interface-pragmas -fomit-interface-pragmas -fsimplify ( -ffloat-lets-exposing-whnf -ffloat-primops-ok -fcase-of-case -freuse-con -fpedantic-bottoms -funfolding-use-threshold-0 -fmax-simplifier-iterations3 ) -himap=.%.hi:/usr/local/ghc-2.04/lib/hslibs/ghc/imports%.hi:/usr/local/ghc-2.04/ lib/hslibs/ghc/imports%.hi:/usr/local/ghc-2.04/lib/imports%.hi -hifile=/tmp/ghc17244.hi -S=/tmp/ghc17244.s +RTS -H7000 -K200 -SLexer.stat -s/tmp/ghc17244.stat swift.ucc.ie:~/filter/tmp2:
Command line tribulations.
Hi all. Some problems I had recently with ghc opts, while trying to twiddle the heap usage of ghc on happy output (see ghc-users, passim). Pedantic observation: contra the user guide, -funfolding-use-threshold0 isn't recognized, though -funfolding-use-threshold-0 is. (The minus/hyphen isn't needed for other values, confusingly.) Neither -optCrts-Sstderr nor -Rgc-stats seem to do anything useful; the file created by the latter contains only a ghc command line, and the former seems to do nothing at all. The option -fshow-simplifier-progress seems to have gone entirely AWOL. In short, apart from what -dshow-passes and -Rgc-stats tell me, I'm pretty in the dark. Aside: am I misreading the format, or does -Rgc-stats always report an average heap residency of 0? The maximum looks fairly sensible, though... Essentially, what I'd like to be able to do is tie some sort of useful residency information from each stage of the compiler. About all I can tell at the moment is that if my compilation runs out of heap it either does it in the core to core stage, or (worryingly) the code generator. Thanks in advance, Alex.
Re: building ghc-2.04-pl2 on DEC alphas
Josh Burdick writes: ghc-0.29 -cpp -fhaskell-1.3 -fglasgow-exts -DCOMPILING_GHC -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils -ibasicTypes -itypes -ihsSyn -iprelude -irename -itypecheck -ideSugar -icoreSyn -ispecialise -isimplCore -istranal -istgSyn -isimplStg -icodeGen -iabsCSyn -imain -ireader -iprofiling -iparser -inativeGen -fomit-derived-read -fomit-reexported-instances -DOMIT_DEFORESTER -H40m -K8m -H10m -c typecheck/TcExpr.lhs -o typecheck/TcExpr.o -osuf o ghc-0.29: ignoring heap-size-setting option (-H10m)...not the largest seen ghc: 327403296 bytes, 29 GCs, 0/8660104 avg/max bytes residency (3 samples), 0.19 INIT (0.05 elapsed), 32.85 MUT (84.80 elapsed), 11.64 GC (111.00 elapsed) :ghc as1: Internal: /usr/tmp/ghc17186.s, line 30: ../../../../../../src/usr/ccs/bin/as/as1util.p, line 460: idn sym_tab.alloc_len Fatal error in: /usr/lib/cmplrs/cc/as1 Segmentation fault - core dumped gmake[2]: *** [typecheck/TcExpr.o] Error 1 I've just been building ghc-2.04 on a 3.2 alpha, and it gets past this stage without apparent difficuly. Here's a log of the last gasp, with suitably spammy dump flags... I don't know what the problem would be, but perhaps a compare and contrast might be illuminating. Cheers, Alex. -- wisdom.ucc.ie pwd /usr/local/users/abf/ghc-2.04/fptools/ghc/compiler wisdom.ucc.ie gnumake typecheck/TcExpr.o EXTRA_HC_OPTS="-v -dshow-passes -H0M -H20M" ghc-0.29 -H50M -K8M -cpp -fhaskell-1.3 -fglasgow-exts -DCOMPILING_GHC -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils -ibasicTypes -itypes -ihsSyn -iprelude -irename -itypecheck -ideSugar -icoreSyn -ispecialise -isimplCore -istranal -istgSyn -isimplStg -icodeGen -iabsCSyn -imain -ireader -iprofiling -iparser -inativeGen -fomit-derived-read -fomit-reexported-instances -DOMIT_DEFORESTER -H10m -v -dshow-passes -H0M -H20M -c typecheck/TcExpr.lhs -o typecheck/TcExpr.o -osuf o ghc-0.29: ignoring heap-size-setting option (-H10m)...not the largest seen ghc-0.29: resetting heap-size to zero!!! The Glorious Glasgow Haskell Compilation System, version 0.29 patchlevel 0 literate pre-processor: echo '#line 1 "typecheck/TcExpr.lhs"' /usr/tmp/ghc31125.lpp; /usr/local/ghc/0.29/lib/ghc/0.29/alpha-dec-osf1/unlit typecheck/TcExpr.lhs - /usr/tmp/ghc31125.lpp real 0.2 user 0.0 sys0.0 Haskellised C pre-processor: echo '#line 1 "typecheck/TcExpr.lhs"' /usr/tmp/ghc31125.cpp; /usr/local/ghc/0.29/lib/ghc/0.29/alpha-dec-osf1/hscpp -v '-DCOMPILING_GHC' '-DOMIT_DEFORESTER' -D__HASKELL1__=3 -D__GLASGOW_HASKELL__=28 -I. -I. -IcodeGen -InativeGen -Iparser -I/usr/local/ghc/0.29/lib/ghc/0.29/alpha-dec-osf1/includes -I/usr/local/ghc/0.29/lib/ghc/0.29/includes /usr/tmp/ghc31125.lpp /usr/tmp/ghc31125.cpp real 0.0 user 0.0 sys0.0 hscpp:CPP invoked: /usr/local/lib/gcc-lib/alpha-dec-osf3.2/2.7.2/cpp -traditional -DCOMPILING_GHC -DOMIT_DEFORESTER -D__HASKELL1__=3 -D__GLASGOW_HASKELL__=28 -I. -I. -IcodeGen -InativeGen -Iparser -I/usr/local/ghc/0.29/lib/ghc/0.29/alpha-dec-osf1/includes -I/usr/local/ghc/0.29/lib/ghc/0.29/includes /usr/tmp/ghc31125.lpp Haskell compiler: /usr/local/ghc/0.29/lib/ghc/0.29/alpha-dec-osf1/hsc ,-H ,-3 ,-N ,-W ,-p ,-InativeGen ,-Iparser ,-Iprofiling ,-Ireader ,-Imain ,-IabsCSyn ,-IcodeGen ,-IsimplStg ,-IstgSyn ,-Istranal ,-IsimplCore ,-Ispecialise ,-IcoreSyn ,-IdeSugar ,-Itypecheck ,-Irename ,-Iprelude ,-IhsSyn ,-Itypes ,-IbasicTypes ,-Iutils ,-I. ,-J/usr/local/ghc/0.29/lib/ghc/0.29/imports/haskell-1.3 ,-J/usr/local/ghc/0.29/lib/ghc/0.29/imports ,/usr/tmp/ghc31125.cpp -fhaskell-1.3 -fglasgow-exts -fomit-derived-read -fomit-reexported-instances -dshow-passes -fomit-interface-pragmas -fsimplify \( -fdo-new-occur-anal -fdo-arity-expand -ffloat-lets-exposing-whnf -ffloat-primops-ok -fcase-of-case -freuse-con -fpedantic-bottoms -fsimpl-uf-use-threshold0 -fessential-unfoldings-only -fmax-simplifier-iterations4 \) -fuse-get-mentioned-vars -v -hi/usr/tmp/ghc31125.hi -fasm-alpha-dec-osf1 -S/usr/tmp/ghc31125.s +RTS -H2000 -K800 -s/usr/tmp/ghc31125.stat Glasgow Haskell Compiler, version 0.29 *** Read: *** Rename: *** TypeCheck: *** DeSugar: *** Core2Core: Simplify *** Core2Stg: *** Stg2Stg: *** Interface: *** CodeGen: real 220.7 user 64.0 sys7.8 ghc: 327629736 bytes, 81 GCs, 0/10364512 avg/max bytes residency (9 samples), 0.04 INIT (0.03 elapsed), 40.37 MUT (132.98 elapsed), 23.62 GC (79.13 elapsed) :ghc Pin on Haskell consistency info: echo ' .text hsc.typecheck.TcExpr.lhs.29.0..:' /usr/tmp/ghc31125.s real 0.0 user 0.0 sys0.0 interface really going into: typecheck/TcExpr.hi Comparing old and new .hi files: cmp -s /usr/tmp/ghc31125.hi typecheck/TcExpr.hi || ( rm -f typecheck/TcExpr.hi cp /usr/tmp/ghc31125.hi typecheck/TcExpr.hi ) real 0.1 user 0.0 sys0.0 Unix assembler: gcc -o typecheck/TcExpr.o -c /usr/tmp/ghc31125.s real 13.1 user 7.4 sys1.9 rm -f
Re: building ghc-2.04-pl2 on DEC alphas
Hi Josh, I'm afraid I can't help directly with any of your main problems, though if I'm feeling brave I may try a build-from-source on an alpha shortly. On some of your other points: Also, could anyone post here a "build.mk" file for building 2.04-pl2 using an 0.29 binary distribution, that definitely worked on alphas ? (or, actually solaris or sun4 would be nice also.) On a Solaris2.5 box, I'm (sucessfully) using the following unprofound stuff. joyce:~/ghc-2.04/build: cat mk/build.mk SRC_HC_OPTS += -H30M INSTALL= $(FPTOOLS_TOP_ABS)/install-sh -c So as far as I can see, nothing that would help with your problems to date... (Compiling with GhcHcOpts= -O -DDEBUG -H40m -K8m -v, I ran out of heap space. Does anyone know how much heap space is enough?) I think the above 30 megs worked OK for me, IIRC, though the makefile -supplied heap sizes don't in some instances. rm -f ghc/PrelBase.o ; if [ ! -d ghc/PrelBase ]; then mkdir ghc/PrelBase ; else exit 0; fi; find ghc/PrelBase -name '*.o' -print | xargs rm -f __rm_food; ../../ghc/driver/ghc -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -split-objs -odir ghc/PrelBase-c ghc/PrelBase.lhs -o ghc/PrelBase.o -osuf o ghc: unrecognised option: -recomp ghc: input file doesn't exist: ghc/PrelBase ghc: You can't use -o or -ohi options if you have multiple input files. Perhaps the -odir option will do what you want. These look to me to be symptoms of invoking the "wrong" compiler at this point; the Prelude, required libraries, etc, need to be built with the newly-built version of ghc -- and the problem here is that it can't, because the build for it has failed. I have to agree that gnumake's determination to plough on with the build after a hideously fatal error can be confusing at times... Thank heavens for large scrollback buffers. So if the small matter of the build for hsc failing is fixed, you should be grand... Good luck, Alex.
Re: Installing 2.04.
Sigbjorn: I'm assuming this is ghc-2.04-pl2 .. It is, or rather ghc-2.04, pacthed to that level. Mind you, I did have to struggle somewhat in applying the patches, as different versions of "patch" seemed to take a varying, and occassionally highly dim viw of how to apply them. So a foul-up on my part is not to be ruled out. what does `head lit2latex` report? It sez: #!/usr/local/bin/perl $TMPDIR="/tmp"; $LIB_ARCH_DIR="/amd/church/ogi/staff/simonpj/BUILDS/spj-working/literate"; $LIB_DIR="/amd/church/ogi/staff/simonpj/BUILDS/spj-working/literate"; $TGRIND_HELPER="/usr/local/lib/tgrind/tfontedpr "; # # This perl script needs the definition of a few `make' # variables to make sense (normally added when `make'ing # it). They are: # Hrm, does look a bit fishy... /bin/sh: @echo: not found A couple of these sillies existed in pl1, but I cannot see that there's any of them left in pl2; where/when did it happen during `make install' ? Incessantly. Example (first place it crops up on re-running on an already installed machine, to be exact): rm -f hscpp Creating hscpp... Done. /bin/sh: @echo: not found /export/home/ferguson/ghc-2.04/build/install-sh -c -g ghc-admin hscpp /usr/local/ghc-2.04/lib This might be due to an xargs with a pitifully small argv buffer, GNU xargs (from GNU findutils) is recommended. If you're already using it, tweaking the source to use a larger buffer is not hard... alternatively, disable splitting. I'm using the GNU version, that was the first thing I checked. All the time seem to be spent in (one single) ar command, so I don't think xargs is the problem, un;ess I misinterpret what occurs. All the above is history, largely, so if it's just a problem with my setup, then no real worries. But -- Bonus problem: Had more hassles trying to rebuild the documentation: joyce:~/ghc-2.04/build/ghc/docs/users_guide: gnumake install ===fptools== Recursively making `install' for ways: p ... PWD = /export/home/ferguson/ghc-2.04/build/ghc/docs/users_guide ==fptools== gnumake way=p install; PWD = /export/home/ferguson/ghc-2.04/build/ghc/docs/users_guide gnumake[1]: Nothing to be done for `install'. ===fptools== Finished recursively making `install' for ways: p ... PWD = /export/home/ferguson/ghc-2.04/build/ghc/docs/users_guide Doesn't actually build anything. Do I need to twiddle the target/ways for this? Couldn't see any mention of this in the (other) docs; maybe it's documented in the stuff I'm trying to build. ;-) Doing: joyce:~/ghc-2.04/build/ghc/docs/users_guide: gnumake user.tex (say) gets someplace, but then falls over on messages like: No file `runtime_control.itex' along LITINPUTS path `.' because runtime_control.itex hasn't already been "made", though invoking gnumake on it in turn works. Maybe this is caused by me using the "wrong" version of lit2latex (cos the right one won't work, see above). Ta, Alex.
Re: making ghc-2.04,linux with ghc-0.29
Sergey, I'm afraid I can't help you with your main problem. None of the (pre-crash) diagnostics looked too bad to me. But until someone competent turns up, here's my best stab at some of your others: I placed 2 in .build.mk - is this right? I suspect it doesn't actually matter, but yes, I this this is OK. It also containsmkdependHS_1_2 = mkdependHS-1.2 But where is defined mkdependHS-1.2 ? It should come with the ghc-0.29 distribution, though it'll simply be called "mkdependHS", most likely. Many lines contain @..@ values. Say, These variables will all be instantiated by "configure", which in turn gets them either from command line arguments, or makes 'em up as it goes along. The options and defaults are given by "configure --help". I found the only one I needed to set was: prefix = @prefix@ Good luck, Alex.
Installing 2.04.
Greetings, fellow buggees. Building 2.04 (on a sun/sparc/solaris2.5 box) seemed to go relatively smoothly, up until I tried to do "make install", whereupon the fun really started. Running into some problems, I decided to resort to (gasp!) checking the installation guide, only to discover it was nowhere in sight -- instead, it has to be built from a .lit file. Has this changed from recent releases, or did I just fail to notice as it was being done automatically? When I tried to build the installation docs, I got the following: swift.ucc.ie:~/ghc-2.04/build/docs: make installing.dvi ../literate/lit2latex -S -c-o installing.itex installing.lit Giant error 'do'ing lit-globals.prl: at ../literate/lit2latex line 636. make: *** [installing.tex] Error 2 Problem with my perl version/installation? I made do by using the 0.29 version of lit2latex, which managed to muddle through. Back to the actual install: I get any number of these: /bin/sh: @echo: not found This didn't happen earlier in the build, nor with 2.03 install. But the real head-scratcher is that the install fails with messages like: for i in libHSposix.a; do \ /export/home/ferguson/ghc-2.04/build/install-sh -c -m 644 -g ghc-admin $i /usr/local/ghc-2.04/lib; \ done libHSposix.a:error reading file But on a different, but supposely identically configured machine, there's no problem. Any clues as to what the diagnostic means? Certainly the file in question exists, and is the in PWD make's looking at. And lastly, and probably nothing to do with ghc at all: has anyone else noticed that "ar" seems to take an ordinately long time to build the libraries? Even with the "q" option, it seems to repeatedly read and write the whole thing several times, which for the epicly huge profiling libraries is positively painful. Do I have a suspect archiver, or is this par for the course: In pain, Alex.
Re: Installing 2.04.
Some darn fool wrote: libHSposix.a:error reading file Any clues as to what the diagnostic means? Oops! Apparently, "file system full". embarrassed cough My excuses are a confusing error message, and a disk partitioning system no one here seems to understand. BTW, isn't it Canonical GHC behaviour for the installer to create a "ghc-2.04", as well as a "ghc" script? It doesn't seem to do that... Foolishly, Alex.
Allegedly ambiguous functions:
SPJ, quoting Marc:
| Could somebody tell me how to disambiguate the following program
|
| module Tmp( g ) where
| data A p q = A
| g :: (Num p,Ord q) = (A p q) - Bool
| g A = g A
I don't understand this. "g" always returns bottom.
If only! The above example looks pathological mainly because Marc was
in Mega-terse mode when producing a canonical example of this bug/feature,
I think; one could expand it back to a more meaningful program, with
the same disambiguation problem.
The trouble here is that compiling this, under 2.02, gives:
tmp.lhs:1: tmp.lhs:4: Ambiguous overloading:
at a use of an overloaded identifier: `g' PrelBase.Ord q{-av0-}
When checking signature(s) for: Tmp.g
2.01 (and earlier) thinks it's OK. I'm not sure which of these is
correct behaviour (or if some tweak in the standard means both are
(or were)).
Alex.
Re: Installing ghc2.03 -- execvp error.
VS: gmake[2]: execvp: ghc-0.29: Arg list too long gmake[2]: *** [hsc] Error 127 Further to my last message, here are the Collected Sayings of the Prophet Finne on the matter: you're fighting with ARG_MAX, try invoking make as follows: foo% env PATH=$PATH make (the Makefile has got a note buried within it about this) and: Sigh, you may be able to get a bit further if you use bash as your SHELL rather than /bin/sh, i.e., make all SHELL=bash If not, a (temporary) workaround is included in the following patches ftp://ftp.dcs.gla.ac.uk/pub/haskell/glasgow/working/ghc-2.03-make.patch where you have to set the environment variable REAL_SHELL to a non-broken shell. I hope either of these mysterious incantations help; I presume from the above I didn't hit the problem as I'm a tcsh (ab)user. (So I haven't tried either, and don't blame me if they don't work.) ;-) Cheers, Alex.
Re: Installing ghc2.03
Hi again, Vladimiro. VS: Exactly. It fails compiling the parser. I'm trying to compile using (the binaries of) ghc-2.02. Is there something intrinsecally wrong with this? Ah-hah! Yes. You need ghc-0.29 as the builder, I believe. I don't know why this might be "instrinsically" wrong, but anecodotally, it don't work. Mercifully you can get this as binaries from Glasgow, so you're not caught in an infinite build loop. (One hopes.) Good luck, Alex.
Re: Installing ghc2.03
Oops, missing the obvious! Vladimiro Sassone types: gmake configure That should be just ./configure no? Or have you tried that already? Cheers, Alex.
Re: System libraries in 2.03
Sven Panne notes: The interface files for the system libraries ghc, hbc, posix and contrib seem to be installed in the wrong place: The lib directory (containing hsc and friends) does not contain a hslibs subdirectory. I noticed (and already reported: is this fixed in the new install script, Sigs?) this too: it seems that they're installed in "lib", ghc looks for them in "lib", but mkDependHS looks for them in "lib/hslibs". I just hacked mkdepend, myself; it may or may not be the Right Thing, but it seemed to work. Slainte, Alex.
2.02: error checking bug.
The following erroneous fragment erroneously compiles. data Token = TokNewline
Re: 2.02: error checking bug.
Here's a much simpler instance of my previous bug report: data A = T | T is missed by ghc-2.02 error-checking, but caught in 2.03. Problem solved in advance, then, really. Alex.
Yet another ghc-2.03 installation problem.
2.03ish make depend seems to provoke errors like: mkdependHS: can't open directory /usr/local/lib/ghc-2.03/hslibs/ghc/imports make: *** [depend] Error 2 I haven't checked back with exactly what the makefiles do, so this is partly conjectural, but my diagnosis, and the basis on which I hacked a fix, was that the install process puts the above into "libdir", while mkdependHS looks for them in "libdir/hslibs". Dunno which is right; I'd guess the first, since the ghc driver seems to agree. Just supposin', Alex.
ghc-2.01 in knots.
Has anyone found a problem with (erroneously, in my case) knot-tied structed pattern matching? I got a bus error (eek) from a fragment of the form: blah b = ... x ... where [x] = ... [x] ... While I'm fairly sure this is what caused the problem, (I did a clean rebuild, so I can't have been a linking problem), I can't reproduce the error in a simple canonical case, at least yet. Alex.
