March 2006 - Glasgow-haskell-users

GHC 6.5 on Mac Os X
by Christopher Brown 30 Mar '06

30 Mar '06

Hi, I am trying to get GHC 6.5 to compile on Mac OS X and I am not having much success. I managed to get the CVS version to build without any problems on my linux machine, and when I followed the same steps to complie on my mac I get errors. Here are the steps I followed on my mac autoreconf ./configure make I am using Happy version 1.14 alex version 2.0.1 I also tried 2 different builds, one using gcc 3.3 and the other using gcc 4.0 With gcc 4.0 I get the following error: ------------------------------------------------------------------------ ==fptools== make all - --no-print-directory -r; in /Users/chrisbrown/fptools/ghc/utils/hsc2hs ------------------------------------------------------------------------ /usr/local/bin//ghc -H16m -O -i../../lib/compat -ignore-package Cabal -Rghc-timing -Wall -c Main.hs -o Main.o -ohi Main.hi /tmp/ghc7100.s:unknown:Undefined local symbol L___DISCARD__$stuc <<ghc: 795261768 bytes, 1901 GCs, 10806254/16691432 avg/max bytes residency (10 samples), 46M in use, 0.10 INIT (0.00 elapsed), 9.72 MUT (42.51 elapsed), 7.31 GC (9.09 elapsed) :ghc>> make[3]: *** [Main.o] Error 1 make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make: *** [build] Error 1 dhcp293e:~/fptools chrisbrown$ And with gcc 3.3 I get: /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/main -istage1/ profiling -istage1/parser -istage1/cprAnalysis -istage1/ ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen - InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc- timing -H16M '-#include "hschooks.h"' -i../lib/compat -ignore- package Cabal -c deSugar/Desugar.lhs -o stage1/deSugar/Desugar.o - ohi stage1/deSugar/Desugar.hi /tmp/ghc7343.s:unknown:Undefined local symbol L___DISCASD__$stub <<ghc: 137823188 bytes, 39 GCs, 5163380/11942184 avg/max bytes residency (4 samples), 23M in use, 0.10 INIT (0.00 elapsed), 1.56 MUT (4.83 elapsed), 1.01 GC (1.29 elapsed) :ghc>> make[2]: *** [stage1/deSugar/Desugar.o] Error 1 make[1]: *** [all] Error 1 make: *** [build] Error 1 dhcp293e:~/fptools chrisbrown$ gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1809) dhcp293e:~/fptools chrisbrown$ These error messages seem to be non-deterministic. I am running Mac OS X 10.4.1 with 1 gig RAM. Cheers, Chris. Christopher Brown Ph.D. Student University of Kent. UK. http://www.cs.kent.ac.uk/people/rpg/cmb21/index.html

5 4

How to access hs_free_fun_ptr from a Visual Studio DLL
by Brian Hulley 28 Mar '06

28 Mar '06

Hi - I have the following declaration and code in part of a DLL I'm writing: extern "C" { typedef void (*HsFunPtr)(); extern __declspec(dllimport) void hs_free_fun_ptr(HsFunPtr fp); } enum ECallback { ECallback_Render, ECallback_COUNT}; HsFunPtr callback[ECallback_COUNT]; void SetCallback(ECallback c, HsFunPtr fp){ if (callback[c]){ hs_free_fun_ptr(callback[c]); } callback[c] = fp; } However when I try to build the DLL, I get the following error from Visual Studio: Duma.obj : error LNK2019: unresolved external symbol __imp__hs_free_fun_ptr So the problem is that the VS is adding __imp__ onto the function name even though I've specified it as extern "C" and is moreover just ignoring the dllimport directive and complaining that it can't find the function. I've also tried deleting the "extern" before the "__declspec" but this doesn't make any difference. Also, I've tried putting hs_free_fun_ptr into the IMPORTS section of the def file but this doesn't make any difference either (I don't even think def files have an IMPORTS section so it's probably just being ignored). I've got a horrible feeling that VS will need a .lib file for ghc to allow it to link against hs_free_fun_ptr but I don't have a clue how to generate one... Does anyone know how I can get everything to link? Thanks, Brian.

5 12

RE: GHC 6.4.2 release candidates
by Simon Marlow 28 Mar '06

28 Mar '06

On 28 March 2006 13:41, Bulat Ziganshin wrote: > Tuesday, March 28, 2006, 3:34:59 PM, you wrote: > >> We're finally in release-candidate mode for 6.4.2. Please grab a > > i've written your email about ghc documentation that lists obsolete > "-ddump" options and don't mention new ones such as "-ddump-cmm". are > you got it? > > i can even scan the ghc 6.4.1 docs and write you about all oddities i > can see. just that i can recall now - "-fgenerics" section says > something about ghc 5.02, "-fparr" is still undocumented, TH section > should contain reference to wiki page and so on Thanks Bulat, I got your earlier message, sorry for not replying. It would be great if you could list these things - please open a ticket on the bug tracker. Cheers, Simon

1 0

Re: Possible runtime overhead of wrapping the IO monad?
by Duncan Coutts 28 Mar '06

28 Mar '06

On Tue, 2006-03-28 at 01:37 +0100, Brian Hulley wrote: > Hi Duncan - > I just declared duma_vertex3f (in another module) by: > > foreign import ccall duma_vertex3f :: Float -> Float -> Float -> IO () > > I thought this means that the C function prototype must be: > > void duma_vertex3f(HsFloat, HsFloat, HsFloat); > > so I don't understand why GHC (or any other Haskell compiler) would ever > need to see a C header file to generate the correct code. What info could be > in the header that is not already in the Haskell type? Because ghc does compile via C and does use the C header files to get the C function prototype. Well it can compile via C and it's recommended when compiling FFI code since it allows the Haskell type you've declared to be checked against the C prototype. The warning you saw was coming from gcc as it compiled the C code emitted by ghc. So it's mostly as a sanity check but actually there is some information in the C prototype that is not reflected in the Haskell type. For example 'const'ness, which is why you might sometimes see warnings from gcc about casting away the const attribute. More seriously there is the single/double issue. In the absence of a prototype C will promote single to double. If the function really was declared as single then using double will probably cause a crash. There are probably other examples where not using a C prototype can lead to trouble. There are more probably details on this issue in the emails during the FFI standardisation process. Interestingly that particular issue is less of a problem when not compiling via C since the Haskell type does provide enough information for making a call using the standard system ABI. C's type sytem (such as it is) has slightly more information in it than just the system ABI needs (such as const). Duncan

3 5

RE: 6.4.1 Bug? getServiceEntry: does not exist (no such service entry)
by Simon Marlow 24 Mar '06

24 Mar '06

Binary snapshots allordy here: http://www.haskell.org/ghc/dist/stable/dist/ Cheers, Simon On 23 March 2006 16:54, S. Alexander Jacobson wrote: > Is there a 6.4.2 binary for winXP? I assuming doing a build from > source is non-trivial. > > -Alex- > > On Thu, 23 Mar 2006, Simon Marlow wrote: > >> S. Alexander Jacobson wrote: >> >>> I just upgraded to 6.4.1 from 6.4.0 and am now getting this error >>> when I run socket code via ghci, but not when I compile the code >>> using ghc. Any idea what this is or how to fix? >>> >>> getServiceEntry: does not exist (no such service entry) >> >> This was reported a while back, and I still have it on my queue to >> investigate: >> >> http://www.haskell.org//pipermail/haskell-cafe/2005-October/011777.html >> >> However, I just checked and it doesn't happen with a recent 6.4.2 >> snapshot, so I'm going to consider it fixed (probably another weird >> mingw version interaction, or something). >> >> Grab a 6.4.2 snapshot and you should be happy. >> >> Cheers, >> Simon >> > > ______________________________________________________________ > S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

4 4

Information for GHC users on Gentoo Linux
by Duncan Coutts 24 Mar '06

24 Mar '06

Information for GHC users on Gentoo Linux: GHC 6.4.1 has finally been marked stable on x86, amd64, sparc and ppc. (We also support ppc64, alpha and hppa.) http://packages.gentoo.org/search/?sstring=ghc We also have a collection of over 30 Haskell libraries and tools: http://packages.gentoo.org/packages/?category=dev-haskell http://packages.gentoo.org/search/?sstring=darcs Not all of these are marked stable yet. To emerge a package that is not yet marked stable, use this command: ACCEPT_KEYWORDS="~x86" emerge {pkgname} (substitute ~x86 for your arch as appropriate) Support and Bugs: * Bugs should be reported in the Gentoo bugzilla: http://bugs.gentoo.org/ * There is also a #gentoo-haskell irc channel on FreeNode. Filing bugs can also be used to ask for new packages or new versions of existing packages. We would like to encourage users to suggest any packages they feel are useful but are currently not included in portage (though note that we generally only package released versions of software where there are tarballs available and where there is an expectation that the software is maintained). For future reference this info is available from the haskell.org wiki: http://haskell.org/haskellwiki/Gentoo We have an ebuild for recent ghc-6.4.2 pre-release snapshots (and also for the latest darcs version of ghc-6.5). Anyone who would like to help us test this should contact us on irc for details. I'd like to thank the other members of Gentoo's Haskell 'herd' for their hard work in testing and fixing bugs which got us to this level of support. Duncan

1 0

6.4.1 Bug? getServiceEntry: does not exist (no such service entry)
by S. Alexander Jacobson 23 Mar '06

23 Mar '06

I just upgraded to 6.4.1 from 6.4.0 and am now getting this error when I run socket code via ghci, but not when I compile the code using ghc. Any idea what this is or how to fix? getServiceEntry: does not exist (no such service entry) FYI, I am running WinXP SP2. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

2 2

6.4.2 release plans
by Simon Marlow 23 Mar '06

23 Mar '06

Hi Folks, This is a heads up for the forthcoming 6.4.2 release. Our rough timescale is to go into release candidate testing in about a week, and have two weeks of release candidates before the final release. Here are the things we know about and plan to fix before the release: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status… If you have anything else for 6.4.2, please let me know. Cheers, Simon

5 5

Re: Threaded runtime error
by Simon Marlow 22 Mar '06

22 Mar '06

Volker Stolz wrote: > * Volker Stolz <stolz(a)i2.informatik.rwth-aachen.de>: > >>timeout@menelaos [20:17:08]> ./timeout 10 /usr/bin/true >>FFatal error '_pq_insert_tail: Already in priority queue' at line 200 in file /usr/src/lib/libpthread/thread/thr_priority_queue.c (errno = 0) > > > A workaround seems to use another threading library here. Both > libthr and libc_r work at least for this small example. > > The error occurs on createOSThread(). I'm not sure where exactly > (ie., for the child or the parent, but I guess the child). > I'll keep on looking. If you can get me a backtrace, that would be most helpful. Cheers, Simon

1 0

Re: 6.4.2 release plans
by Simon Marlow 22 Mar '06

22 Mar '06

Duncan Coutts wrote: > Chris Parrott found that ghc-6.4.1 doesn't work with gcc 4.1 on amd64, > although it does work on x86. > > The error manifests itself as link errors due to undefined symbols: > > /var/tmp/portage/ghc-6.4.1-r2/work/ghc-6.4.1/ghc/rts/libHSrts.a(Linker.o):(.data+0x48): undefined reference to `StgReturn' > /var/tmp/portage/ghc-6.4.1-r2/work/ghc-6.4.1/ghc/rts/libHSrts.a(RtsStartup.o): In function `hs_add_root': > RtsStartup.c:(.text+0x1a8): undefined reference to `StgRun' Coincidentally, I just upgraded our x86_64 box to FC5, and the nightly build fell over with exactly these errors. It turns out that the HEAD already had fixes in some arch's for this, but it was fixed by making StgRunIsImplementedInAssembler() non-static. The attribute fix is better, so I've applied it consistently and merged to 6.4.2. Cheers, Simon

1 0