GHC 6.4 release candidates available
We are finally at the release candidate stage for GHC 6.4. Snapshots with versions 6.4.20050209 and later should be considered release candidates for 6.4. Source and Linux binary distributions are avaiable here: http://www.haskell.org/ghc/dist/stable/dist/ Please test if you're able to, and give us feedback. Thanks! Simons & the GHC team
"Simon Marlow"
We are finally at the release candidate stage for GHC 6.4. Snapshots with versions 6.4.20050209 and later should be considered release candidates for 6.4.
Using: ghc-6.4.20050209-i386-unknown-linux.tar.bz2 $ cat hello.hs main = putStrLn "hello world" $ ghc--6.4.20050209 -o hello hello.hs ld: cannot find -lHSbase_cbits collect2: ld returned 1 exit status $ Pretty much a show-stopper. Regards, Malcolm
"Simon Marlow"
We are finally at the release candidate stage for GHC 6.4. Please test if you're able to, and give us feedback.
In versions 5.00 <= ghc <= 6.2.2, the result of ghc -v 2>&1 | head -2 was something like Glasgow Haskell Compiler, Version 6.2.2, .... Using package config file: /grp/haskell/lib/ghc-6.2.2/package.conf whereas with 6.4, these two lines have been swapped: Reading package config file: /usr/malcolm/local/lib/ghc-6.4.20050209/package.conf Glasgow Haskell Compiler, Version 6.4.20050209, .... and the "Using package config" message has become "Reading package config". These changes are minor and unnecessary: in particular they make the detection of configuration information (by hmake) rather more complicated than it ought to be. I know this is a pretty trivial complaint, but the -v behaviour has been stable for a few years now, so why change it arbitrarily? Regards, Malcolm
$ ghc-pkg-6.4.20050209 --show-package=base --field=import_dirs ["/usr/malcolm/local/lib/ghc-6.4.20050209/imports"] yet $ ghc-pkg-6.4.20050209 --show-package=base-1.0 --field=import_dirs ghc-pkg: cannot find package base-1.0 $ ghc-pkg-6.4.20050209 --list-packages /usr/malcolm/local/lib/ghc-6.4.20050209/package.conf: rts-1.0, base-1.0, haskell98-1.0, template-haskell-1.0, ... Regards, Malcolm
On Thu, 2005-02-10 at 13:11 +0000, Simon Marlow wrote:
Please test if you're able to, and give us feedback.
I've noticed that running main of the attached code, using Proxy
data-types to simulate context parameters (see previous email) still
sends something into an infinite loop; is this my fault or GHCs?
-Si.
--
Simon David Foster
When -fglasgow-exts is on, (#) no longer seems to be recognized. (I get a parse error.) however # works fine as an infix operator. John -- John Meacham - ⑆repetae.net⑆john⑈
There seems to have been a change in how packages are found which is biting me. I have a module called PackedString, which used to be fine, as ghc's packedstring was called Data.PackedString. however with ghc 6.4 I am getting the error: Atom.hs:3:0: Failed to load interface for `PackedString': Could not find module `PackedString': it is a member of package lang-1.0, which is hidden If not using -package foo doesn't allow you to reuse the names in foo then I must wonder what the point is of hiding the package in the first place :) John -- John Meacham - ⑆repetae.net⑆john⑈
If I have two simple modules, Module1 and Module2 like this;
module Module1 where
f = "hello"
module Module2 where
import Module1
I load up Module2 in GHCi, and I can evaluate f in Module1;
Compiling Module1 ( ./Module1.hs, interpreted )
Compiling Module2 ( Module2.hs, interpreted )
Ok, modules loaded: Module2, Module1.
*Module2> f
"hello"
Now I change Module1 to
module Module1 where
f = "hello2"
and reload; this happens in the GHC 6.4 RC:
*Module2> :r
Compiling Module1 ( ./Module1.hs, interpreted )
Skipping Module2 ( Module2.hs, interpreted )
Ok, modules loaded: Module2, Module1.
Prelude Module2>
And I can no longer get at anything in Module1 (this is generally true
of any imported modules), only stuff in Module2. Instead I have to do a
full reload. In GHC 6.2, if you did this it reloaded both modules and
everything was fine, so I'm guessing this is incorrect behaviour.
-Si.
--
Simon David Foster
And one other niggle, if you try and load a module which doesn't exist with :m, it doesn't load it, but it still appends it to command-line; Prelude> :m + My.Module Top level: Failed to load interface for `My.Module': Could not find module `My.Module': use -v to see a list of the files searched for Prelude My.Module> -Si. On Fri, 2005-02-11 at 13:50 +0000, Simon David Foster wrote:
If I have two simple modules, Module1 and Module2 like this;
module Module1 where f = "hello"
module Module2 where import Module1
I load up Module2 in GHCi, and I can evaluate f in Module1;
Compiling Module1 ( ./Module1.hs, interpreted ) Compiling Module2 ( Module2.hs, interpreted ) Ok, modules loaded: Module2, Module1. *Module2> f "hello"
Now I change Module1 to
module Module1 where f = "hello2"
and reload; this happens in the GHC 6.4 RC:
*Module2> :r Compiling Module1 ( ./Module1.hs, interpreted ) Skipping Module2 ( Module2.hs, interpreted ) Ok, modules loaded: Module2, Module1. Prelude Module2>
And I can no longer get at anything in Module1 (this is generally true of any imported modules), only stuff in Module2. Instead I have to do a full reload. In GHC 6.2, if you did this it reloaded both modules and everything was fine, so I'm guessing this is incorrect behaviour.
-Si.
--
Simon David Foster
For commands other than register, ghc-pkg --user operates on both the user and global package databases, whereas the the docs and online help says it operates on the user database only. Also, ghc-pkg list queries only the system database (unless --user is given), but the the docs say it queries both.
Please test if you're able to, and give us feedback.
It looks like GADTs (or something else new) conflict with normal Haskell'98 type inference. The following example used to compile just fine with all previous versions of ghc and nhc98. $ ghc-6.4.20050210 -package lang -c -o Parse.o Parse.hs Parse.hs:209:4: Couldn't match the rigid variable `a' against the rigid variable `a1' `a' is bound by the type signature for `parseValdef' `a1' is bound by the type signature for `parseWhere' Expected type: Parser (Decls TokenId) [PosToken] a1 Inferred type: Parser (Decls TokenId) [(Pos, Lex, Lexical.LexState, [LexPre.PosTokenPre])] a In the expression: ((((lit L_where) `revChk` lcurl) `revChk` parseDecls) `chk` rcurl) `orelse` (parse (DeclsParse [])) In the definition of `parseWhere': parseWhere = ((((lit L_where) `revChk` lcurl) `revChk` parseDecls) `chk` rcurl) `orelse` (parse (DeclsParse [])) The quoted expressions look a little bit hairy, but if you examine the explicit type signatures in question, it is very clear that there should be no error here. To reproduce the bug, just build the nhc98 compiler proper. $ wget ftp://ftp.cs.york.ac.uk/pub/haskell/nhc98/nhc98src-1.17.tar.gz $ tar zxf nhc98src-1.17.tar.gz $ ./configure --buildwith=ghc-6.4.20050210 $ make basic Regards, Malcolm
So my hack to get ghc working on x86-64 is a bit trickier with the new version, all that is needed is to make sure -m32 is passed to gcc, as, and ld and everything works great with the i386 build of ghc. for earlier versions, I set extra_ghc_opts = ["-optc-m32", "-optl-m32", "-opta-m32"] for base in package.conf. However in 6.4 there no longer seems to be an extra_ghc_opts in package.conf. I was able to add -m32 to extraCcOpts and extraLdOpts, but there does not appear to be an extraAsOpts. perhaps this is an oversight? John It would be nice if ghc always passed -m32 when targeted to i386-*-* since it does not hurt when you are actually on a 32 bit system but would save us x86-64 people some hassle. -- John Meacham - ⑆repetae.net⑆john⑈
System.Posix.Types.CClock and System.Posix.Types.CTime seem to be missing instances for 'Integral' as they used to have. John -- John Meacham - ⑆repetae.net⑆john⑈
On Thu, Feb 10, 2005 at 01:11:48PM -0000,
Simon Marlow
We are finally at the release candidate stage for GHC 6.4. Snapshots with versions 6.4.20050209 and later should be considered release candidates for 6.4.
One of my platforms is still not recognized: preston:~/tmp/ghc-6.4.20050212 % ./configure configure: loading site script /usr/local/etc/config.site configure: creating cache /usr/local/var/tmp/config.cache checking build system type... sparc64-unknown-netbsd2.0.1 checking host system type... sparc64-unknown-netbsd2.0.1 checking target system type... sparc64-unknown-netbsd2.0.1 Unrecognised platform: sparc64-unknown-netbsd2.0.1 Now, I understand that it is a rather uncommon platform but I would like to run darcs on it. ghc runs fine on my other UltraSparc 10, which runs Debian/GNU/Linux. hugs runs fine on the Sparc/NetBSD. I've read http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.html#SE... but it is still unclear for me. When I compile ghc on the Sparc / Debian, no ".hc" files are produced.
If a program calls exitWith, runghc produces an extra line of output: *** Exception: exit: ExitSuccess or *** Exception: exit: ExitFailure 3 and then exits with status 0. It should do what a ghc-compiled program does: silently exit with the appropriate status.
On Thu, Feb 10, 2005 at 01:11:48PM -0000, Simon Marlow wrote:
We are finally at the release candidate stage for GHC 6.4. Snapshots with versions 6.4.20050209 and later should be considered release candidates for 6.4.
Source and Linux binary distributions are avaiable here:
http://www.haskell.org/ghc/dist/stable/dist/
Please test if you're able to, and give us feedback.
Thanks!
Simons & the GHC team
Hi, I just noticed that in GHC.PArr, productP is defined wrongly productP :: (Num a) => [:a:] -> a productP = foldP (*) 0 in (the likely) case that PArr is deprecated, you may want to add a DEPRECATED-pragma. Groetjes, Remi -- Nobody can be exactly like me. Even I have trouble doing it.
Remi Turk
I just noticed that in GHC.PArr, productP is defined wrongly
productP :: (Num a) => [:a:] -> a productP = foldP (*) 0
in (the likely) case that PArr is deprecated, you may want to add a DEPRECATED-pragma.
I have just discovered that module recently through the paper "An Approach to Fast Arrays in Haskell" at http://www.cse.unsw.edu.au/~chak/papers/CK03.html I have found a bug in enumFromToP from http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/ base/GHC/PArr.hs?rev=1.7 enumFromThenToP 6 5 1 ==> [:6,5,4:] enumFromThenToP 10 8 1 ==> [:10,8,6:] Mentioning this on the friendly #haskell channel got me this suggestion: "TheHunter: hmm, i think enumFromThenToP = ... replicateP (((z - x) `div` delta) + 1) delta does the trick." Regards, Peter Eriksen
When I compile a simple code importing Control.Monad.State with ghc-6.4.20050217 on Linux I get linking errors: % cat foo.hs import Control.Monad.State main = putStr "Hello\n" % ghc foo.hs foo.o(.text+0x145): In function `__stginit_Main_': : undefined reference to `__stginit_ControlziMonadziState_' collect2: ld returned 1 exit status % The same works with the --make option: % ghc --make foo.hs Chasing modules from: foo.hs Compiling Main ( foo.hs, foo.o ) Linking ... % I tried both the linux binary and to compile GHC from source. Akos -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Akos Korosmezey Tel: +36-1-439-5936 Ericsson Telecom Ltd. ETH/GSCD/RUNB Fax: +36-1-437-7576 P.O.B. 107, H-1300 Budapest, Hungary Home: +36-26-342-687 mailto:Akos.Korosmezey@ericsson.com Mobile: +36-30-740-7732 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Akos Korosmezey wrote:
When I compile a simple code importing Control.Monad.State with ghc-6.4.20050217 on Linux I get linking errors: [...]
You have to use "-package mtl" when "--make" is not used, because mtl (where Control.Monad.State resides) is not an auto package, for more details see: http://haskell.org/ghc/docs/latest/html/users_guide/packages.html Cheers, S.
Hi, Compiling 6.4.20050217 on Windows according to the book fails pretty early: <snippet> /cygdrive/c/ghc/ghc-6.2.2/bin//ghc -H16m -O -I. -Rghc-timing -I../../../librari es -fglasgow-exts -no-recomp -c Compat/RawSystem.hs -o Compat/RawSystem.o -o hi Compat/RawSystem.hi c:/DOCUME~1/JOSEFS~1/LOKALA~1/Temp/ghc3868.hc: In function `s3SQ_entry': c:/DOCUME~1/JOSEFS~1/LOKALA~1/Temp/ghc3868.hc:109: too many arguments to functio n `rawSystem' </snippet> Cheers, /Josef
2 issues (6.4.20050218): Compiling on OS X 10.2.8 (using gcc 3.1, ghc-6.2.2) gave an error on ghc/rts/Linker.c. The tarball includes a bogus version of ghc/includes/ghcplatform.h, which from what I can tell ought to be generated by make. Deleting the file and re-making seemed to work for a while. (Also, should that file be removed by make clean? It doesn't seem to be...) Later on in the compilation, though, I got another error (pasted below) on ghc/rts/Apply.cmm. Thanks, -Judah ../../ghc/compiler/ghc-inplace -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c Apply.cmm -o Apply.o Apply.cmm:28: illegal external declaration, missing `;' after `section' Apply.cmm:52: syntax error, found `1' Apply.cmm:52: illegal method selector, found `*' Apply.cmm:52: illegal method definition, missing `{' after `)' Apply.cmm:53: illegal external declaration, missing `;' after `again' Apply.cmm:53: illegal method definition, found `+' Apply.cmm:53: illegal method definition, missing `{' after `]' Apply.cmm:53: illegal external declaration, found `goto' Apply.cmm:53: syntax error, found `0' Apply.cmm:53: illegal method selector, found `*' Apply.cmm:53: illegal method definition, missing `{' after `)' Apply.cmm:53: illegal external declaration, found `default' Apply.cmm:78: undefined type, found `bits32' Apply.cmm:79: undefined type, found `bits32' Apply.cmm:83: illegal expression, found `%' Apply.cmm:90: illegal external declaration, found `if' Apply.cmm:90: syntax error, found `Words' Apply.cmm:90: illegal method selector, found `*' Apply.cmm:96: undefined type, found `jump' Apply.cmm:109: undefined type, found `bits32' Apply.cmm:110: undefined type, found `bits32' Apply.cmm:113: illegal external declaration, found `for' Apply.cmm:115: syntax error, found `i' Apply.cmm:115: illegal method selector, found `*' Apply.cmm:115: illegal method definition, missing `{' after `]' Apply.cmm:118: illegal external declaration, found `goto' Apply.cmm:127: undefined type, found `bits32' Apply.cmm:128: illegal expression, found `%' Apply.cmm:129: undefined type, found `bits32' Apply.cmm:130: illegal expression, found `%' Apply.cmm:131: illegal external declaration, found `if' Apply.cmm:132: illegal method selector, found `0' Apply.cmm:132: illegal method definition, missing `{' after `)' Apply.cmm:134: illegal external declaration, found `if' Apply.cmm:135: illegal method selector, found `0' Apply.cmm:135: illegal method definition, missing `{' after `)' Apply.cmm:137: illegal external declaration, found `if' Apply.cmm:138: syntax error, found `-' Apply.cmm:138: illegal method selector, found `*' Apply.cmm:138: illegal method definition, missing `{' after `)' Apply.cmm:141: undefined type, found `jump' Apply.cmm:143: undefined type, found `jump' Apply.cmm:144: illegal expression, found `%' Apply.cmm:157: syntax error, found `0' Apply.cmm:157: illegal function definition, found `)' Apply.cmm:159: undefined type, found `bits32' Apply.cmm:160: undefined type, found `bits32' Apply.cmm:164: illegal expression, found `%' Apply.cmm:172: illegal function prototype, found `(' Apply.cmm:172: illegal function definition, found `)' Apply.cmm:172: undefined type, found `SIZEOF_StgHeader' Apply.cmm:172: syntax error, found `+' Apply.cmm:172: illegal method selector, found `)' Apply.cmm:172: illegal method definition, missing `{' after `)' Apply.cmm:174: syntax error, found `-' Apply.cmm:174: illegal function definition, found `)' Apply.cmm:175: undefined type, found `SIZEOF_StgHeader' Apply.cmm:175: syntax error, found `+' Apply.cmm:175: illegal method selector, found `)' Apply.cmm:175: illegal method definition, missing `{' after `)' Apply.cmm:186: undefined type, found `bits32' Apply.cmm:187: undefined type, found `bits32' Apply.cmm:190: illegal external declaration, found `for' Apply.cmm:192: syntax error, found `i' Apply.cmm:192: illegal method selector, found `*' Apply.cmm:192: illegal method definition, missing `{' after `]' Apply.cmm:195: illegal external declaration, found `goto' Apply.cmm:204: undefined type, found `bits32' Apply.cmm:205: illegal expression, found `%' Apply.cmm:206: undefined type, found `bits32' Apply.cmm:207: illegal expression, found `%' Apply.cmm:208: illegal external declaration, found `if' Apply.cmm:209: illegal method selector, found `0' Apply.cmm:209: illegal method definition, missing `{' after `)' Apply.cmm:211: illegal external declaration, found `if' Apply.cmm:212: illegal method selector, found `0' Apply.cmm:212: illegal method definition, missing `{' after `)' Apply.cmm:214: illegal external declaration, found `if' Apply.cmm:215: syntax error, found `-' Apply.cmm:215: illegal method selector, found `*' Apply.cmm:215: illegal method definition, missing `{' after `)' Apply.cmm:218: undefined type, found `jump' Apply.cmm:220: undefined type, found `jump' Apply.cmm:221: illegal expression, found `%' Apply.cmm:236: syntax error, found `0' Apply.cmm:236: illegal function definition, found `)' Apply.cmm:238: undefined type, found `bits32' Apply.cmm:239: undefined type, found `bits32' Apply.cmm:251: illegal function prototype, found `(' Apply.cmm:251: illegal function definition, found `)' Apply.cmm:251: undefined type, found `SIZEOF_StgHeader' Apply.cmm:251: syntax error, found `+' Apply.cmm:251: illegal method selector, found `)' Apply.cmm:251: illegal method definition, missing `{' after `)' Apply.cmm:253: syntax error, found `-' Apply.cmm:253: illegal function definition, found `)' Apply.cmm:254: undefined type, found `SIZEOF_StgHeader' Apply.cmm:254: syntax error, found `+' Apply.cmm:254: illegal method selector, found `)' Apply.cmm:254: illegal method definition, missing `{' after `)' Apply.cmm:265: undefined type, found `bits32' Apply.cmm:266: undefined type, found `bits32' Apply.cmm:269: illegal external declaration, found `for' Apply.cmm:271: syntax error, found `i' Apply.cmm:271: illegal method selector, found `*' Apply.cmm:271: illegal method definition, missing `{' after `]' Apply.cmm:274: illegal external declaration, found `goto' Apply.cmm:280: illegal method definition, found `+' Apply.cmm:280: illegal method definition, missing `{' after `]' Apply.cmm:280: illegal external declaration, found `goto' Apply.cmm:280: syntax error, found `0' Apply.cmm:280: illegal method selector, found `*' Apply.cmm:280: illegal method definition, missing `{' after `)' Apply.cmm:280: illegal external declaration, found `default' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode /Users/judah/unix/haskell/ghc-6.4pre/ghc-6.4.20050217/ghc/includes/Cmm.h:65:0: lexical error make[1]: *** [Apply.o] Error 1 make: *** [all] Error 1
OK, never mind on the second count; it turned out that Apple's gcc
v3.1 preprocessor can't handle c-- files. Switching to gcc v.3.3
fixed that issue.
-Judah
On Sat, 19 Feb 2005 11:40:23 -0500, Judah Jacobson
2 issues (6.4.20050218):
Compiling on OS X 10.2.8 (using gcc 3.1, ghc-6.2.2) gave an error on ghc/rts/Linker.c. The tarball includes a bogus version of ghc/includes/ghcplatform.h, which from what I can tell ought to be generated by make. Deleting the file and re-making seemed to work for a while. (Also, should that file be removed by make clean? It doesn't seem to be...)
Later on in the compilation, though, I got another error (pasted below) on ghc/rts/Apply.cmm.
Thanks, -Judah
Hello, I'm having some serious "issues" getting GHC to run on Suse 9.2/x86 (or x86-64 for that matter, although I didn't really expect that to work without some pain and suffering). I've had no luck with 6.2.2, or any 6.4 release candidate. Here is a typical example: after doing a "./configure; make in-place", I get the following: /home/bstrand/haskell/ghc-6.4.20050221/lib/i386-unknown-linux/ghc-6.4.20050221: error while loading shared libraries: libreadline.so.4: cannot open shared object file: No such file or directory Fair enough; "rpm -q readline" gives me readline-5.0-1.2. So off to the sources I go: cd ~/src/ghc-6.4.20050221 ./configure ... configure: error: GHC is required unless bootstrapping from .hc files. After reading through most of the GHC building guide (paying particular attention to section 10), I try: ./configure --enable-hc-boot After a few minutes, this dies with: ==fptools== make boot -wr; in /home/bstrand/src/ghc-6.4.20050221/libraries/base ------------------------------------------------------------------------ touch GHC/PrimopWrappers.hs make[2]: *** No rule to make target `System/CPUTime_hsc.c', needed by `depend'. Stop. make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050221/libraries' make: *** [build] Error 1 "./configure --enable-hc-boot --enable-hc-boot-unregisterised" fails with the same error. Running "distrib/hc-build" runs for much longer, but then ends with the now familiar: ===fptools== Recursively making `boot' in base haskell98 template-haskell unix Cabal parsec readline ... PWD = /home/bstrand/src/ghc-6.4.20050221/libraries ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==fptools== gmake boot -wr; in /home/bstrand/src/ghc-6.4.20050221/libraries/base ------------------------------------------------------------------------ gmake[1]: *** No rule to make target `System/CPUTime_hsc.c', needed by `depend'. Stop. gmake: *** [boot] Error 1 gmake: Leaving directory `/home/bstrand/src/ghc-6.4.20050221/libraries' Having spent about 10 hours on it over the weekend, I decided it was time to call in the pros. So, any advice on getting a working ghc on Suse 9.2 x86 and/or x86-64 would be greatly appreciated.
Brian Strand wrote:
Hello,
I'm having some serious "issues" getting GHC to run on Suse 9.2/x86 (or x86-64 for that matter, although I didn't really expect that to work without some pain and suffering). I've had no luck with 6.2.2, or any 6.4 release candidate. Here is a typical example: after doing a "./configure; make in-place", I get the following:
/home/bstrand/haskell/ghc-6.4.20050221/lib/i386-unknown-linux/ghc-6.4.20050221: error while loading shared libraries: libreadline.so.4: cannot open shared object file: No such file or directory
Fair enough; "rpm -q readline" gives me readline-5.0-1.2.
How about just installing readline4 (or whatever package provides libreadline.so.4)? :) Jens
Jens Petersen wrote:
Brian Strand wrote:
Hello,
I'm having some serious "issues" getting GHC to run on Suse 9.2/x86 (or x86-64 for that matter, although I didn't really expect that to work without some pain and suffering). I've had no luck with 6.2.2, or any 6.4 release candidate. Here is a typical example: after doing a "./configure; make in-place", I get the following:
/home/bstrand/haskell/ghc-6.4.20050221/lib/i386-unknown-linux/ghc-6.4.20050221:
error while loading shared libraries: libreadline.so.4: cannot open shared object file: No such file or directory
Fair enough; "rpm -q readline" gives me readline-5.0-1.2.
How about just installing readline4 (or whatever package provides libreadline.so.4)? :)
Jens
I was trying to "do the right thing" and report whatever was broken in the ghc bootstrapping process :) But shortly after my post I broke down and installed readline-compat (which on Suse 9.2 luckily happens to have libreadline.so.4), which fixes my problem on x86. Unfortunately I'm still stuck on x86-64, since there are no "official" binaries to bootstrap from on that platform. But at least I have a ghc to play with while waiting for x86-64 to become official. Thanks for the assistance, Brian
Brian Strand wrote:
Jens Petersen wrote:
Brian Strand wrote:
Hello,
I'm having some serious "issues" getting GHC to run on Suse 9.2/x86 (or x86-64 for that matter, although I didn't really expect that to work without some pain and suffering). I've had no luck with 6.2.2, or any 6.4 release candidate. Here is a typical example: after doing a "./configure; make in-place", I get the following:
/home/bstrand/haskell/ghc-6.4.20050221/lib/i386-unknown-linux/ghc-6.4.20050221:
error while loading shared libraries: libreadline.so.4: cannot open shared object file: No such file or directory
Fair enough; "rpm -q readline" gives me readline-5.0-1.2.
How about just installing readline4 (or whatever package provides libreadline.so.4)? :)
Jens
I was trying to "do the right thing" and report whatever was broken in the ghc bootstrapping process :) But shortly after my post I broke down and installed readline-compat (which on Suse 9.2 luckily happens to have libreadline.so.4), which fixes my problem on x86.
Unfortunately I'm still stuck on x86-64, since there are no "official" binaries to bootstrap from on that platform. But at least I have a ghc to play with while waiting for x86-64 to become official.
Thanks for the assistance, Brian
There are some debian packages of ghc 6.2.2 and related stuff for amd64 located here: http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ghc6... Hopefully you can find some way to convert these to a format you can install (there are programs for converting debian packages to rpms I think, but I can't remember what they are called - google is your friend). After installing this binary, bootstrapping an (at least unregistered) amd64 ghc 6.4 should be possible. Cheers, Anders
Anders Höckersten wrote: ...
There are some debian packages of ghc 6.2.2 and related stuff for amd64 located here: http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ghc6...
Hopefully you can find some way to convert these to a format you can install (there are programs for converting debian packages to rpms I think, but I can't remember what they are called - google is your friend).
After installing this binary, bootstrapping an (at least unregistered) amd64 ghc 6.4 should be possible.
Cheers, Anders
Thanks a lot! For anyone who runs into the same problem, here is what I did: 1. Converted to an rpm via "alien -r ghc6_6.2.2-3_amd64.deb" 2. Installed the resulting rpm. 3. When I tried to run ghc6, I got /usr/lib/ghc-6.2.2 # /usr/bin/ghc6 ghc-6.2.2: Can't find package.conf as /usr/lib/ghc-6.2.2/ghc/driver/package.conf.inplace Other similar errors cropped up while trying to bootstrap. So, some crude symlink hackery: cd /usr/lib/ghc-6.2.2 ln -s . ghc ln -s . driver ln -s package.conf.shipped package.conf.inplace # now we have a /usr/lib/ghc-6.2.2/ghc/driver/package.conf.inplace mkdir utils ln -s .. utils/unlit # now we have a /usr/lib/ghc-6.2.2/utils/unlit/unlit ln -s ghc6 /usr/bin/ghc # so ./configure finds ghc This has gotten me quite a ways into the 6.2.2 compile; I'm still waiting to see if it completes successfully. Brian
Brian Strand wrote:
Unfortunately I'm still stuck on x86-64, since there are no "official" binaries to bootstrap from on that platform. But at least I have a ghc to play with while waiting for x86-64 to become official.
There is a x86_64 build already in Fedora Haskell. Perhaps you can try it? It may work for you. Jens
Jens Petersen wrote:
Brian Strand wrote:
Unfortunately I'm still stuck on x86-64, since there are no "official" binaries to bootstrap from on that platform. But at least I have a ghc to play with while waiting for x86-64 to become official.
There is a x86_64 build already in Fedora Haskell. Perhaps you can try it? It may work for you.
Jens
I found some x86-64 binaries thanks to Anders' helpful suggestion (posted yesterday) at: http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ghc6... Thanks, Brian
On Thu, Feb 10, 2005 at 01:11:48PM -0000, Simon Marlow wrote:
We are finally at the release candidate stage for GHC 6.4. Snapshots with versions 6.4.20050209 and later should be considered release candidates for 6.4.
Source and Linux binary distributions are avaiable here:
http://www.haskell.org/ghc/dist/stable/dist/
Please test if you're able to, and give us feedback.
All the below with 2c7ed0ee7a11f2eae159d073c29b4fe6 ghc-6.4.20050228-src.tar.bz2 The following files in the tarball look like they shouldn't be there (and should be cleaned by at least distclean): * ghc/includes/mkGHCConstants (an x86 ELF binary) * ghc/driver/package.conf.inplace.old * ghc/driver/package.conf.old * A large number of ld.script files and the _split directories they are in * libraries/{OpenAL,X11,base,network,unix}/config.status * libraries/config.status After building, then doing make distclean, I'm additionally left with: * A ghc/compiler/stage1 directory tree including a number of .hi-boot-5 and .hi-boot-6 files. * A ghc/compiler/stage2 directory tree including a number of .hi-noot and .o-boot files. * A complete libraries/html directory * libraries/libraries.txt * mk/config.h * mk/config.mk * mk/stamp-h but "Building from source" / "Standard Targets" says: distclean Delete all files from the current directory that are created by configuring or building the program. If you have unpacked the source and built the program without creating any other files, make distclean should leave only the files that were in the distribution. I think you have unswapped the first two lines of "ghc -v 2>&1 | head -2" but not changed "Reading" back to "Using", so old hmakes are still broken (old includes the latest release, I believe). Is there an equivalent of this (the no-OpenGL bit): $(MAKE) prefix=`pwd`/debian/tmp/usr install GhcLibsWithOpenGL=NO GhcLibsWithGLUT=NO that still works or do I have to do it by hand? Thanks Ian
Ian Lynagh wrote:
[...] Is there an equivalent of this (the no-OpenGL bit):
$(MAKE) prefix=`pwd`/debian/tmp/usr install GhcLibsWithOpenGL=NO GhcLibsWithGLUT=NO
that still works or do I have to do it by hand?
The OpenGL/GLUT/OpenAL packages (and a few others) are enabled automatically if the right headers/libs are found during the configuration stage, otherwise they are disabled. If you don't want these packages to be built, even if the right headers/libs are available on the build platform, just give --disable-opengl/--disable-glut/--disable-openal options to configure. Cheers, S.
Ian Lynagh
ghc-6.4.20050228-src.tar.bz2
I think you have unswapped the first two lines of "ghc -v 2>&1 | head -2" but not changed "Reading" back to "Using", so old hmakes are still broken (old includes the latest release, I believe).
There are a couple of other configuration changes needed in hmake to support ghc-6.4 as well, so there will be a new release shortly. Regards, Malcolm
participants (17)
-
Akos Korosmezey -
Anders Höckersten -
Brian Strand -
Ian Lynagh -
Jens Petersen -
John Meacham -
Josef Svenningsson -
Judah Jacobson -
Malcolm Wallace -
Peter Eriksen -
Remi Turk -
Ross Paterson -
ross＠soi.city.ac.uk
-
Simon David Foster -
Simon Marlow -
Stephane Bortzmeyer -
Sven Panne