- Glasgow-haskell-users

6.4.1 release candidate testing
by Simon Marlow 05 Aug '05

05 Aug '05

This is to announce that testing for 6.4.1 has begun. Snapshots from 20050730 onwards are release candidates - please test if you can. Snapshots are available from here: http://www.haskell.org/ghc/dist/stable/dist/ we have source snapshots, and binaries for Linux/x86 (RH 9.1 era), Linux/x86_64 (FC3 era), and Windows. A *huge* number of fixes have gone in since 6.4. Also, big news is that Linux/x86_64 will have a new native code generator and GHCi support (including Template Haskell), so we'd especially like to hear from anyone that can test on Linux/x86_64. The GHCi support isn't complete: the interpreter can't currently handle FFI, and there are problems with data references to shared libraries from dynamically-loaded .o files, but otherwise it should be functional. We're planning for a release in 1-2 weeks. I'm going to be offline for a while from mid-Aug, but hopefully we'll get the release out before then. Please remember to put the full version number in any bug report, and happy testing! Cheers, Simon

7 10

Problem with SHGetFolderPath using Cabal on Windows 98
by Toby Allsopp 05 Aug '05

05 Aug '05

When trying to use Cabal (e.g. running `runghc Setup.lhs' for HSQL or running `ghci -package Cabal') on Windows 98, I get an error like the following: C:/GHC/GHC-6.4.1/HSCabal.o: unknown symbol `_SHGetFolderPathA' This happens with GHC 6.4 and ghc-6.4.1.20050803-i386-unknown-mingw32.tar.gz. I believe that the problem is that the SHGetFolderPath function is not included in SHELL32.DLL in Windows 98. If the appropriate updates are installed (new IE, I think) then it is available in SHFOLDER.DLL. It is also available in SHFOLDER.DLL in later versions of Windows. I also believe, but haven't been able to verify, that #includeing <shfolder.h> before using SHGetFolderPath will fix it. I guess changing something in libraries/Cabal/Distribution/Simple/Configure.hs will do the trick, but I don't know much about the FFI. Cheers, Toby.

1 1

RE: 6.4.1 release candidate testing
by Simon Marlow 04 Aug '05

04 Aug '05

On 04 August 2005 11:43, Ralf Hinze wrote: >> Please ignore last night's snapshot (3/8), something is broken. > > The message came in too late ;-). Anyway, 3/8 compiled fine (using > 1/8) > and it seems to work. Environment: > > patronus ghc-6.4.1.20050803 # uname -a > Linux patronus 2.6.12-gentoo-r7 #1 Wed Aug 3 18:57:28 CEST 2005 > x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux > > BTW, I am especially thankful that ghci works again! 3/8 works, but there is a bug in the simplifier that means that in rare cases your program may go *very* slowly. I've just fixed it, anyway. Cheers, Simon

1 0

RE: 6.4.1 release candidate testing
by Simon Marlow 04 Aug '05

04 Aug '05

Please ignore last night's snapshot (3/8), something is broken. Cheers, Simon

2 1

problems building trhsx-0.2 with ghc-6.5.20050723
by Niklas Broberg 04 Aug '05

04 Aug '05

> Cabal hides all packages when using GHC 6.5. Add 'base' to > build-depends in trhsx's cabal file and send a patch to the author. Lemmih has it right, I haven't gone over and fixed this in my packages. I guess I should... Vadim, thanks for the patch. /Niklas

1 0

RE: 6.4.1 release candidate testing under solaris
by Simon Marlow 04 Aug '05

04 Aug '05

On 03 August 2005 16:35, Gour wrote: > Christian Maeder (maeder(a)tzi.de) wrote: > >> What is the name of the cvs tag that I sould use, then? >> >> (currently I have "ghc-6-4-branch") > > I'm not sure about that. > > I simply downloaded from ghc-6.4.1.20050801-src.tar.bz2 from > > http://www.haskell.org/ghc/dist/stable/dist/. ghc-6-4-branch is the right tag if you're getting sources from CVS. Cheers, Simon

1 0

RE: 6.4.1 release candidate testing
by Simon Marlow 03 Aug '05

03 Aug '05

On 03 August 2005 09:58, Gour wrote: > Gabriel Ebner (ge(a)gabrielebner.at) wrote: > >> I think you can do away with the first line too, I've just done a >> successful build with split objects on gentoo/amd64. > > Is there any advantage in split-build? Binary sizes are smaller (much smaller). Cheers, Simon

3 4

RE: 6.4.1 release candidate testing under solaris
by Simon Marlow 03 Aug '05

03 Aug '05

On 03 August 2005 12:54, Christian Maeder wrote: > I get for the cvs version of today under solaris: > > Cheers Christian > > [...] > stage1/ghci/ByteCodeItbls.o: In function `s641_info': > ghc11717.hc:(.text+0x2c38): undefined reference to `stgMallocBytesRWX' > collect2: ld returned 1 exit status > <<ghc: 13100660 bytes, 3 GCs, 145896/145896 avg/max bytes residency (1 > sample > s), 15M in use, 0.01 INIT (0.00 elapsed), 0.13 MUT (11.37 elapsed), > 0.01 GC ( > 0.04 elapsed) :ghc>> > gmake[2]: *** [stage1/ghc-6.4.1] Error 1 > gmake[1]: *** [all] Error 1 I think you must be building using an earlier 6.4.1 snapshot. You can workaround the problem by disabling GHCI: add GhcWithInterpreter=NO to mk/build.mk. You can turn it back on again before building stage2, if you like. Cheers, Simon

1 0

RE: 6.4.1 release candidate testing
by Simon Marlow 03 Aug '05

03 Aug '05

On 03 August 2005 13:20, Gour wrote: > Simon Marlow (simonmar(a)microsoft.com) wrote: > >> That's right, split objects is now working on amd64 too. > > Confirmed. > >> That's what I like to hear, bugs that fix themselves! > > Here is another one of those, i.e. there are several problems with > the docs > building, e.g.: Thanks, fixed. Simon

1 0

RE: 6.4.1 release candidate testing
by Simon Marlow 03 Aug '05

03 Aug '05

On 03 August 2005 09:27, Gabriel Ebner wrote: > Gour wrote: > >>> I don't notice any particular tweaking in the ghc ebuild. Did you >>> uncomment the GhcWithInterpreter and SplitObjs lines in the ebuild? >> >> I just tweaked the 2nd line to: >> >> use ppc64 && echo "GhcWithInterpreter=NO" >> mk/build.mk >> >> so I can get 'ghci' built. > > I think you can do away with the first line too, I've just done a > successful build with split objects on gentoo/amd64. That's right, split objects is now working on amd64 too. >>> I'll try to rebuild ghc on my gentoo box, maybe it works this >>> time... >> >> Pls. report back if everything is fine. > > I must've touched the magic switch. Now it's running just fine. > Apparently HTYPE_TCFLAGS_T got undef'd the first time, but now it's > good, although I don't know what I did. That's what I like to hear, bugs that fix themselves! Cheers, Simon

2 1