June 2005 - Glasgow-haskell-users

RE: state of GHC-6.4 on Solaris?
by Simon Marlow 29 Jun '05

29 Jun '05

[ forwarding to glasgow-haskell-useres(a)haskell.org ] On 28 June 2005 13:13, Christian Maeder wrote: > I've copied a fresh binary distribution (from June 27th) of ghc-6.4.1 > for solaris to: > > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/ hets/solaris/ghc-6.4.1-sparc-sun-solaris2.tar.bz2 > > It was configured with: > > ./configure --disable-opengl --disable-glut --disable-openal > > and compiled using gcc_3.4.4 > > ghci (and thus template haskell) does not work! The error shows up as: > > Loading package mtl-1.0 ... > > GHCi runtime linker: fatal error: I found a duplicate definition for > symbol _module_registered I've uploaded this distribution to haskell.org, here: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris2 .tar.bz2 Cheers, Simon

1 0

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

29 Jun '05

On 29 June 2005 04:47, Ian Lynagh wrote: > On Tue, Jun 28, 2005 at 12:14:08PM +0100, Simon Marlow wrote: >> On 27 June 2005 17:53, Michiel Buddingh' wrote: >> >>> 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. >> >> That looks like a sanity check that has bitrotted. You can ignore it >> until you need to get 'foreign import "wrapper"' working. > > This works (or at least compiles!) on Linux/Alpha: Committed, thanks. Simon

1 0

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

29 Jun '05

On 27 June 2005 17:53, Michiel Buddingh' wrote: > 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. Ok, I suggest you do a 'make -k' in ghc/rts. The .cmm files should at least generate .hc files, that you can take to the target machine. > 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) Ok, I assume you'll discover in due course whether you need this on Alpha or not. > 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. That looks like a sanity check that has bitrotted. You can ignore it until you need to get 'foreign import "wrapper"' working. > 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. More bitrot. Please send us patches when you've got the compiler bootstrapped. Cheers, SImon

2 1

Re: [Haskell] ANNOUNCE: GHC survey results
by John Meacham 28 Jun '05

28 Jun '05

On Tue, Jun 28, 2005 at 01:27:39PM +0100, 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 Unfortunatly hat suffers from the same problem that pretty much every non-trivial preprocessor does, as soon as you start using ghc's special or experimental features that have not been added to hat yet, they stop working. Big complicated programs tend to be the ones you want to debug and also are the ones where you most likely needed to use a new extension... I am not sure what the general solution would be. perhaps hat being integrated with ghc? or better yet would be a standard interface for ghc to call a preprocessor but at some intermediate level where most of the extensions have been sugared away but most of the original source structure still exists... the nice thing about a standard interface would be that jhc and other compilers could support it too. It wouldn't even need to be a plugin based thing, but rather an executable that ghc can run and pass commands to it on stdin and read results on stdout. Being able to just work on any unmodified program the compiler supports is a huge feature. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

6.4.1?
by John Meacham 28 Jun '05

28 Jun '05

Any word on 6.4.1? The major FFI bug in 6.4 is holding back some projects of mine. John -- John Meacham - ⑆repetae.net⑆john⑈

4 6

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