- Glasgow-haskell-users

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

STM and unsafePerformIO
by Robert van Herk 03 Aug '05

03 Aug '05

Hello All, I think I've read somewhere that STM doesn't like unsafePerformIO. However, I would like to use a global STM variable. Something like this: *module* Main *where* import GHC.Conc import System.IO.Unsafe tSid = unsafePerformIO (atomically (newTVar 0)) tickSessionID :: STM Int tickSessionID = *do* sid <- readTVar tSid writeTVar tSid (sid + 1) return sid main = atomically tickSessionID But, when I try this, the evaluation of main causes a segmentation fault. Is there a workaround for this bug? Regards, Robert

2 3

RE: STM and unsafePerformIO
by Simon Marlow 03 Aug '05

03 Aug '05

On 03 August 2005 11:51, Robert van Herk wrote: > I think I've read somewhere that STM doesn't like unsafePerformIO. > However, I would like to use a global STM variable. Something like > this: > > *module* Main *where* > import GHC.Conc > import System.IO.Unsafe > > tSid = unsafePerformIO (atomically (newTVar 0)) > > tickSessionID :: STM Int > tickSessionID = > *do* sid <- readTVar tSid > writeTVar tSid (sid + 1) > return sid > > main = atomically tickSessionID > > But, when I try this, the evaluation of main causes a segmentation > fault. Is there a workaround for this bug? You're ok as long as the global variable doesn't get evaluated inside another atomically. The problem is that nested atomically isn't supported; the RTS gets confused. For example, you could say main = do evaluate tSid ... to force evaluation of tSid before doing anything else. Cheers, Simon

1 0

RE: Bug in placing _stub.o files with HEAD
by Simon Marlow 03 Aug '05

03 Aug '05

On 01 August 2005 15:19, Einar Karttunen wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: >> I thought I fixed this in CVS recently (rev. 1.54 of >> Distribution.Simple.Build to be exact). Are you running Cabal from >> CVS, or some other version? > > Cabal from CVS. The versions are GHC 6.5.20050728 and Cabal-1.1.2. > > I created a small Cabal package to demonstrate the problem. > http://www.cs.helsinki.fi/u/ekarttun/haskell/test-hs-source-dirs-w-fexp. tar.gz > > The _stub.o file is not added into the static library. Thanks, should be fixed now. Cheers, Simon

1 0

RE: Installation problem
by Simon Marlow 03 Aug '05

03 Aug '05

On 02 August 2005 20:00, Dieter Büttner wrote: > I have a X86_64 architecture. So you may be right. In which lib > directory ghc-6.4-1 is looking for libgmp? There I could install the > 32 bit version. It depends on which flavour of Linux you have, but for example on our Fedora Core 3 box here: > locate libgmp /usr/lib64/libgmpxx.so.3 /usr/lib64/libgmpxx.so.3.0.5 /usr/lib64/libgmp.so.3.3.3 /usr/lib64/libgmp.a /usr/lib64/libgmpxx.so /usr/lib64/libgmpxx.a /usr/lib64/libgmp.so.3 /usr/lib64/libgmp.so /usr/lib/libgmpxx.so.3 /usr/lib/libgmpxx.so.3.0.5 /usr/lib/sse2/libgmpxx.so.3 /usr/lib/sse2/libgmpxx.so.3.0.5 /usr/lib/sse2/libgmp.so.3.3.3 /usr/lib/sse2/libgmp.so.3 /usr/lib/libgmp.so.3.3.3 /usr/lib/libgmp.so.3 Cheers, Simon

1 0

RE: making ghc-6.4.1-august-1
by Simon Marlow 03 Aug '05

03 Aug '05

On 03 August 2005 08:06, Serge D. Mechveliani wrote: > I tried to make ghc-6.4.1.20050801-src.tar.bz2 > > with ghc-cvs-6.4.1-july-12 on Debian Linux. > > ( > uname -m > i686 > > uname -r > 2.4.27-2-686-smp > ). > > It reports > > --------------------------------- > ... > System/Directory/Internals.hs:1:0: > conflict: module `System.Directory.Internals' > belongs to the current program/library and also to package > base-1.0 <<ghc: 19592712 bytes, 5 GCs, 79280/79280 avg/max bytes > residency (1 samples), 16M in use, 0.01 INIT (0.00 elapsed), 0.11 MUT > (0.33 elapsed), > 0.10 GC (0.09 elapsed) :ghc>> > make[4]: *** [System/Directory/Internals.o] Error 1 > --------------------------------- > > Should I install ghc-6.4.1.20050801-binary and then compile its > source? Yes, please try building with either 6.4 or the latest 6.4.1. There may be intermediate stages that have problems. Cheers, Simon

1 0