- Glasgow-haskell-users

ghci - relocation error : libreadline
by alexandre 28 Jun '05

28 Jun '05

Hello all, I just installed GHC 6.4 from RPM on a Linux/Mandriva 10.1. When i try to start GHCI i get the following error message : ************************************************************************ GHC Interactive, version 6.4, for Haskell 98. Loading package base-1.0 ... linking ... done. /usr/lib/ghc-6.4/ghc-6.4: relocation error: /usr/lib/libreadline.so.5: symbol __sprintf_chk, version GLIBC_2.3.4 not defined in file libc.so.6 with link time reference ************************************************************************ Could someone help me solve this problem ? For the GHC RPM installation, i had to install readline 5 first, so i now have two version of readline on my system : 4.3 and 5 (... and a lot of application depending on 4.3). Thanks in advance for your help, Alexandre

1 0

Re: [Haskell] ANNOUNCE: GHC survey results
by Christian Maeder 28 Jun '05

28 Jun '05

Thomas Davie wrote: > On 28 Jun 2005, at 10:58, Simon Marlow wrote: > >> We've finally digested the results of the GHC survey, and you can find >> our analysis here: >> >> http://www.haskell.org/ghc/survey2005-summary.html >> >> There's a lot to take in, but it's an interesting read. Enjoy! > I feel compelled to point out that for all those people wanting a > debugger, Hat is there, it's under active development, and it isn't > going away for a while. It even sports a forward tracer as people seem > to want (hat-anim). > > http://www.haskell.org/hat I think, I was stopped by a bad support for my hierarchical module names in hat-2.02. From "How complete is Hat?" I can hardly imagine it will work for my code (so I did not even try the latest release), Christian

1 0

RE: 6.4.1?
by Simon Marlow 28 Jun '05

28 Jun '05

On 28 June 2005 08:58, John Meacham wrote: > On Tue, Jun 28, 2005 at 03:00:46AM +0100, Claus Reinke wrote: >>> I'd like to second this - the Win32 problems in 6.4 are preventing >>> several projects from moving forward. Any word on 6.4.1? The major >>> FFI bug in 6.4 is holding back some projects of mine. >> >> if you have projects depending on this, I assume you are aware of the >> nightly development snapshots and build logs (for both HEAD and >> STABLE; not many platforms, but including linux and windows/mingw)? >> >> http://www.haskell.org/ghc/download.html (bottom) >> >> (nightly snapshots for windows have not always been available, but >> now >> that they are, thanks to Sigbjorn, it would be good to make use of >> them - >> not just to get rid of bugs in the last release, but to avoid bugs >> in the next one) > > Yeah, I should have said that I have projects waiting to be released > until people can compile with a standard version of ghc. Asking people > to install a cvs snapshot is not something I want to do. :) You can work around the FFI problem - just use a C function to return the pointer value instead of foreign import "&". You can even inline the C function and compile via-C to get the same code. I had in mind a timescale of 1-2 months for 6.4.1 - there's various other stuff on my queue first. We want to have a performance shakedown for one thing, and I'd really like 6.4.1 to have GHCi on x86-64. Cheers, Simon

1 0

Re: References to the Rts in unregisterised first build of ghc 6.4
by Michiel Buddingh' 27 Jun '05

27 Jun '05

On Mon, Jun 27, 2005 at 01:00:01PM +0100, Simon Marlow wrote: > On 26 June 2005 18:28, Michiel Buddingh' wrote: > > I was able to generate a set of .hc files on a linux-i386 host, but > > (as was expected) the rtc failed to build. > > Where exactly did the RTS build fail? Can you post the error message? > We do need the .hc files generated from the RTS .cmm source files. Adjustor.c:106:27: machine/pal.h: No such file or directory Adjustor.c: In function createAdjustor': Adjustor.c:403: error: PAL_imb' undeclared (first use in this function) Adjustor.c:403: error: (Each undeclared identifier is reported only once Adjustor.c:403: error: for each function it appears in.) I didn't take a look at this before, but I suspect machine/pal.h might even be specific to OSF/1. Other alterations (in reverse order) Edited out the -mieee gcc flag from /ghc/compiler/main/DriverFlags.hs (gcc-i386 doesn't understand it, and even on Alpha, removing it probably wouldn't break the build process itself) Commented out: #if alpha_TARGET_ARCH checkFEDArgs arg_tys = check (integral_args <= 32) err where integral_args = sum [ machRepByteWidth rep | (rep,hint) <- map typeMachRepRep arg_tys, hint /= FloatHint ] err = ptext SLIT("On Alpha, I can only handle 4 non-floating-point arguments to foreign export dynamic") from TcForeign.lhs. typeMachRepRep was nowhere to be found (not in ghc-6.4, or any earlier released version), and I wasn't able to figure out what, exactly, it does. It seemed like an RTS thing, so I decided to comment it out, and the build proceded. Not sure if that was such a wise idea now. Commented out: import PrimRep ( getPrimRepSize, isFloatingRep ) from the same file. The file isn't included with ghc anymore, and the imported functions weren't used. -- -- Michiel

1 0

RE: References to the Rts in unregisterised first build of ghc 6.4
by Simon Marlow 27 Jun '05

27 Jun '05

On 26 June 2005 18:28, Michiel Buddingh' wrote: > I wanted to run ghc on netbsd-alpha, so I thought I'd build an > unregisterised ghc following the instructions in chapter 10 of the > build manual. > > I was able to generate a set of .hc files on a linux-i386 host, but > (as was expected) the rtc failed to build. Where exactly did the RTS build fail? Can you post the error message? We do need the .hc files generated from the RTS .cmm source files. > However, attempting to compile these .hc files on alpha yields lots of > unresolvable references to stg_ap_0_ret (and other similarly named > functions), which, a quick search revealed, are exported by the rtc. Yes, it looks like you're missing bits of the RTS. Cheers, Simon

1 0

References to the Rts in unregisterised first build of ghc 6.4
by Michiel Buddingh' 26 Jun '05

26 Jun '05

Hello, I wanted to run ghc on netbsd-alpha, so I thought I'd build an unregisterised ghc following the instructions in chapter 10 of the build manual. I was able to generate a set of .hc files on a linux-i386 host, but (as was expected) the rtc failed to build. However, attempting to compile these .hc files on alpha yields lots of unresolvable references to stg_ap_0_ret (and other similarly named functions), which, a quick search revealed, are exported by the rtc. Is this a configuration error on my Alpha (say, I don't need files like libraries/base/Control/Arrow.hc for a first unregistered build) or rather an error on the Linux host that generated the .hc files? I've noticed that mk/config.mk seems to contain several variables that seem to relate to unregisterised builds (such as BootingFromUnregisteredHc) that are neither specified in the hc-build script or the manual. Tuning these on the target machine has no effect. I'd be grateful for any helpful hints. -- -- Michiel

1 0

Parse error on '#'
by Remko Troncon 25 Jun '05

25 Jun '05

Hi, I'm trying to get GHC working on Mac OS X 10.2. I downloaded and installed the binary distribution of GHC 6.0.1, and it seems to compile the 'hello world' application. However, when i try to compile another program (e.g. GHC 6.0.1 itself), it seems that GHC doesn't recognize '#ifdef' statements in code, and reports back with the error: Package.hs:1: parse error on input `#' Can anyone tell what's going on here ? thanks, Remko

2 2

Faster IO
by Jim Apple 24 Jun '05

24 Jun '05

I'm having an IO speed problem. I need to input a long string of known length and process it with a foldl. getLine and foldl take way too long; is there a known faster way? Jim

4 3

GHC 6.2.2 Compile problem on Mac OS X 10.4
by Remko Troncon 23 Jun '05

23 Jun '05

Hi, I am trying to make an unregisterised build. As my host machine, i use a Mac running Mac OS X 10.4. When building ghc 6.2.2 on the host machine (also running GHC 6.2.2), i get the error attached below when doing 'make all' in ghc/. Does anyone have an idea how to solve this ? thanks, Remko ** /usr/local/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes - istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename - istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/ specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn - istage1/simplStg -istage1/codeGen -istage1/absCSyn -istage1/main - istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ compMan -istage1/ndpFlatten -istage1/cbits -DOMIT_NATIVE_CODEGEN - cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser - recomp -Rghc-timing -O -H32m -fasm -H16M '-#include "hschooks.h"' - no-recomp -H80m -c prelude/PrimOp.lhs -o stage1/prelude/PrimOp.o - ohi stage1/prelude/PrimOp.hi primop-tag.hs-incl:2: Warning: Pattern match(es) are overlapped In the definition of `tagOf_PrimOp': tagOf_PrimOp op = ... /tmp/ghc6793.s:83646:Fixup of 78156 too large for field width of 16 bits /tmp/ghc6793.s:83644:Fixup of 78164 too large for field width of 16 bits <<ghc: 1305569372 bytes, 47 GCs, 14631871/36633452 avg/max bytes residency (6 samples), 86M in use, 0.00 INIT (0.00 elapsed), 13.81 MUT (17.74 elapsed), 4.61 GC (5.65 elapsed) :ghc>> make: *** [stage1/prelude/PrimOp.o] Error 1

2 1

unofficial pre-6.4.1 snapshot build for x86-64 linux
by Jens Petersen 23 Jun '05

23 Jun '05

I build a recent 6.4 stable branch snapshot on Linux/x86-64 (ie amd64) today. Since several people expressed interest in it I just uploaded it as binary dist tarball to: http://haskell.org/~petersen/ghc-6.4.1.20050620-x86_64-unknown-linux.tar.gz I'm happy to say with this gtk2hs now works well on x86-64. :-) Rpms of it and gtk2hs are also available on request. Cheers, Jens

1 0