- Glasgow-haskell-users

ghc for SuSE. Reply
by Serge D. Mechveliani 20 Mar '06

20 Mar '06

To my request on GHC-6.4.1 for SuSE 10.0 Christian Maeder <maeder(a)tzi.de> writes on 17 Mar 2006 >> First, we install it to the system area from binary found on the GHC www >> page as >> Binary x86, Generic Linux with glib 2.3. > This binary is not for a 64 bit arch, I think. >> /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld: cannot find -lreadline > you may try: > http://www.haskell.org/ghc/dist/6.4.1/ghc-6.4.1-x86_64-unknown-linux.tar.bz2 Thank you. I have installed it to my user directory. Now, again, it reports --------- ghc $doconCpOpt --make Main Chasing modules from: Main Skipping Main ( Main.hs, Main.o ) Linking ... /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld: cannot find -lreadline collect2: ld returned 1 exit status ---------- > which ghc /home/mechvel/ghc/6.4.1/binary/inst/bin/ghc -- this is of ghc-6.4.1-x86_64-unknown-linux.tar.bz2 . There also is visible /home/mechvel/ghc/6.4.1/binary/inst/lib/ghc-6.4.1/libHSreadline.a But it, probably, searches for shared library in other place. Maybe, we need to remove this old ghc- x86 Generic Linux with glib 2.3, to think of path, etc. We shall try. ----------------- Serge Mechveliani mechvel(a)botik.ru

2 2

RE: 6.4.2 release plans
by Simon Marlow 20 Mar '06

20 Mar '06

On 18 March 2006 18:32, Ian Lynagh wrote: > On Wed, Mar 15, 2006 at 04:24:14PM +0000, Simon Marlow wrote: >> >> If you have anything else for 6.4.2, please let me know. > > Just a small thing, but it looks like, while the HEAD has been changed > to send --help output to stdout, ghc-6.4.2.20060316 still has the > following in ghc/compiler/main/DriverFlags.hs > > dump ('$':'$':s) = hPutStr stderr progName >> dump s > dump (c:s) = hPutChar stderr c >> dump s > > Is this deliberate, or could it be changed to > > dump ('$':'$':s) = putStr progName >> dump s > dump (c:s) = putChar c >> dump s > > please? Done Simon

1 0

ForeignPtr's - why can't they be passed directly to foreign functions?
by Brian Hulley 19 Mar '06

19 Mar '06

Hi - I've got the beginnings of an API for a GUI system as follows: data DWindow a data DEdit a type Window = DWindow type Edit a = DWindow (DEdit a) foreign import ccall duma_init :: IO () foreign import ccall duma_run :: IO () foreign import ccall duma_release :: FunPtr (Ptr (Window a) -> IO ()) foreign import ccall duma_createEdit :: IO (Ptr (Edit a)) foreign import ccall duma_addTop :: Ptr (Window a) -> IO () createEdit :: IO (ForeignPtr (Edit a)) createEdit = do edit <- duma_createEdit newForeignPtr duma_release edit addTop :: ForeignPtr (Window a) -> IO () addTop w = withForeignPtr w duma_addTop This works, but it seems a bit of a pain to have to manually convert between ForeignPtr's and Ptr's all the time. In particular, for the definition of addTop, I tried: foreign import ccall "duma_addTop" addTop :: ForeignPtr (Window a) -> IO () but got an error because ForeignPtr's are not allowed as part of the type of a foreign function. Since the definition of ForeignPtr is just void *, I wonder why this restriction exists - ie is a ForeignPtr not just the same address as the corresponding Ptr? My other question is what happens if I want to have a function that takes more than one ForeignPtr as argument ie foreign import ccall duma_test :: Ptr (Window a) -> Ptr (Window a) -> IO () test :: ForeignPtr (Window a) -> ForeignPtr (Window a) -> IO () test p q = withForeignPtr p (\p' -> withForeignPtr q $ duma_test p') Is this the only way to achieve this? It seems a bit long-winded and possibly a bit inefficient... One other question: if I use forkIO within Haskell, am I right in thinking that the lightweight concurrent threads are safe to use with my single threaded C code ie that there is no danger of a thread being preemptively halted while it is inside a foreign function? Thanks, Brian.

6 9

6.4.1 for SuSE-10.0 lib64
by Serge D. Mechveliani 17 Mar '06

17 Mar '06

Dear GHC team, We are trying to install ghc-6.4.1 on SuSE Linux 10.0, lib64. First, we install it to the system area from binary found on the GHC www page as Binary x86, Generic Linux with glib 2.3. Now, ~> rpm -qa | grep compat says compat-curl2-32bit-7.11.0-7.2 compat-32bit-2004.11.13-4 compat-libstdc++-5.0.7-6 compat-readline4-4.3-4 compat-2004.11.13-4 compat-curl2-7.11.0-7.2 Then, ghc makes the project (under Cabal), creates .o, .a libraries, after runhaskell Setup.hs install --user Then, ghc $dmCpOpt --make Main 'makes' the user module and needs to link all libraries. It reports --------- Chasing modules from: Main Skipping Main ( Main.hs, Main.o ) Linking ... /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld: cannot find -lreadline collect2: ld returned 1 exit status source/demotest> --------- We simplified the project to a single module module DPrelude (sublists) where sublists :: [a] -> [[a]] sublists [] = [[]] sublists (x:xs) = (map (x:) ls) ++ ls where ls = sublists xs The libraries are made of this module. The "user" program is module Main where import DPrelude main = let ll = sublists [1, 2 :: Integer] in putStr "abc" >> writeFile "fl" "abc" >> getChar >> putStr (shows ll "\n") >> appendFile "fl" "1" And it faills with this"readline". ------------------------------------------------------------------------- Then, we try the module which does not use newly created library, but uses input-output: main = putStr "abc" >> writeFile "fl" "abc" >> getChar >> putStr "abc" >> appendFile "fl" "1" And it makes and runs all right. ------------------------------------------------------------------------ Then, I tried to "make" GHC from source by this binary GHC. "configure" does not tell anything about Alex and Happy -- although I do not see them (forgotten of them). It finishes with exit 0, as if nothing has happened. Then, > make reports something which ends (after a couple of minutes) with utils/PrimPacked.lhs:263:0: Warning: foreign declaration uses deprecated non-standard syntax In file included from /tmp/ghc31185.hc:6: /usr/local/lib/ghc-6.4.1/include/HsReadline.h:5:31: error: readline/readline.h:\ No such file or directory /usr/local/lib/ghc-6.4.1/include/HsReadline.h:6:30: error: readline/history.h: \ No such file or directory <<ghc: 101068136 bytes, 20 GCs, 3654882/7854280 avg/max bytes residency (4 samp\ les), 20M in use, 0.00 INIT (0.00 elapsed), 0.27 MUT (0.81 elapsed), 0.11 GC (0\ .13 elapsed) :ghc>> make[2]: *** [stage1/utils/PrimPacked.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/mechvel/ghc/6.4.1/ghc-6.4.1/ghc' make: *** [build] Error 1 Please, can you advise, how to make ghc-6.4.1 work under the above system? Does it matter the difference between lib64 and lib32 ? (we could remain with lib32). ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

newbie: building ghc
by Mark Greenbank 16 Mar '06

16 Mar '06

Hi, Sorry for the newbie question ... I'm trying to build the compiler and I'm getting the following error: [root@quark ghc-6.4.1]# ./configure --prefix=/usr/pkg checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 Canonicalised to: i386-unknown-solaris2 checking for path to top of build tree... /usr/pkg/src/ghc-6.4.1 checking for ghc... no checking for nhc... no checking for nhc98... no checking for hbc... no configure: error: GHC is required unless bootstrapping from .hc files. Does this somehow mean that I need the compiler in order to build the compiler? Thanks, Mark

2 3

Mixing registerised and unregisterised builds
by Ian Lynagh 16 Mar '06

16 Mar '06

Hi all, The attached e-mail seems to be about a problem using a library compiled with an unregisterised ghc with a registerised ghc. The linking step is giving many "undefined reference to `stg_ap_p_ret'"s (with various numbers of 'p's) as well as a few to `GHCziIOBase_zdWIO_entry', and possible others I didn't spot, while compiling haskelldb with a registerised ghc 6.4.1, where haskelldb depends on hsql, which was compiled with an unregisterised ghc 6.4.1. Is this expected behaviour? i.e. should I just make sure I don't change which arches are registerised within a GHC version? If so, would a library compiled with a registerised ghc being used by an unregisterised ghc also cause problems? Or have I got the problem completely wrong? Based on a quick look at the GHC source, the missing symbols seem to be due to this, in ghc/rts/Linker.c : #ifdef TABLES_NEXT_TO_CODE #define RTS_RET_SYMBOLS /* nothing */ #else #define RTS_RET_SYMBOLS \ [...] SymX(stg_ap_p_ret) \ [...] #endif being toggled due to this, in ghc/includes/RtsConfig.h : #if !defined(USE_MINIINTERPRETER) && !defined(ia64_HOST_ARCH) && !defined (powerpc64_HOST_ARCH) #define TABLES_NEXT_TO_CODE #endif in turn due to this, in ghc/includes/Makefile : ifeq "$(GhcUnregisterised)" "YES" SRC_CC_OPTS += -DNO_REGS -DUSE_MINIINTERPRETER endif Thanks Ian

2 3

re: ghc on on macbook pro (fwd)
by ghc＠reillyhayes.com 14 Mar '06

14 Mar '06

I for one would love to see support for my macbook soone than 6.6 -reilly hayes

2 1

Re: registering packages in ghc using a directory of package files
by Duncan Coutts 13 Mar '06

13 Mar '06

On Mon, 2006-03-13 at 13:17 +0000, Simon Marlow wrote: > Duncan Coutts wrote: > > > Attached is the current patch I'm testing. > > I think I've said in the past that in principle I like the idea. I'll > commit your patch. Great. > In terms of making this a feature we advertise in the documentation, I > think we could tweak the details a bit. Sure. > I had in mind allowing -package-conf to specify either a directory or > a file, with the obvious interpretation. I think that's how I did a version of this patch a year or so ago. > Also, with your patch, each file in package.conf.d contains a list of > packages. Yes. > Having just a single package per file seems cleaner, Yes it does. > unless you have a good reason to want the possibility for multiples. > I realise this means wider-ranging changes. It was just that this was the simplest change that reused as much code as possible. Coincidentally it is also how we keep the per-package .conf files in gentoo, ie they're installed package.conf databases rather than indivdual package files. There are reasons we did that in gentoo but they're not essential. For ghc I'd recommend a dir of individual package files. The other problem with my patch is that each .conf file that is loaded up is it's own package db so ghc-pkg reports: /usr/lib64/ghc-6.4.1/package.conf.d/hsql-postgresql-1.7.conf: hsql-postgresql-1.7 /usr/lib64/ghc-6.4.1/package.conf.d/hsql-sqlite-1.7.conf: hsql-sqlite3-1.1 /usr/lib64/ghc-6.4.1/package.conf: rts-1.0, base-1.0, haskell98-1.0, template-haskell-1.0, unix-1.0, parsec-1.0, haskell-src-1.0, network-1.0, QuickCheck-1.0, HUnit-1.1, mtl-1.0, fgl-5.2, stm-1.0, readline-1.0, (lang-1.0), (concurrent-1.0), (posix-1.0), (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0) But this is just because I was taking a very simple approach in my patch. It would obviously be better to consider a single directory of individual package files to be one package database. That will of course need more code changes. Then to do this fully there would need to be further changes to use a dir as ghc's main package db rather than the current file, and to get ghc-pkg to understand directory package dbs so it could register packages in them. Duncan

2 1

printing No. of reductions in GHCi
by RHafiz 13 Mar '06

13 Mar '06

Hello there Is there anyway to find out the number of reductions per execution in GHC? (In Hugs , :set +s prints no of reductions but in GHC, the same command prints time and memory.) Thanks a lot in advance. RHafiz -- View this message in context: http://www.nabble.com/printing-No.-of-reductions-in-GHCi-t1262464.html#a334… Sent from the Haskell - Glasgow-haskell-users forum at Nabble.com.

2 1

registering packages in ghc using a directory of package files
by Duncan Coutts 13 Mar '06

13 Mar '06

All, Yet again I've got annoyed by the difficulties with the way ghc registers packages. It's hard to get right. This time I had someone testing hdbc-odbc for me on ppc64. He uninstalled ghc and reinstalled it (to pick up a fix I had made) then he found that building hdbc-odbc failed because the hdbc package was not registered. However portage (the Gentoo package management facility) knew that it was installed. Of course what happened is that when ghc was reinstalled all the ghc packages that were already installed were not re-registered. Actually that is my fault because our ghc ebuild is supposed to do this. (Technically to do this correctly we should re-register the packages in dependency order, but we don't and just use --force) The point is that there are several bits that the packaging system has to get right for this to all work. The majority of the code in our ghc-package.eclass is for dealing with this issue. If we could just have ghc use a directory of package files rather than registering via modifying one central file then this would all become much simpler and more robust. One concern is that it would remove a point where the package database can be checked for consistency. I don't think this is necessarily so. The place that this QA check is really important is when users are manually installing packages. If an package management system finds a QA problem at registration time then it's already an unrecoverable bug. So the ghc-pkg could continue to be used in the way it is now, it will do it's carious checks and then install a file into a global package.conf.d directory rather than modifying a global package.conf file. For distro packaging systems we could use "ghc-pkg --check" or something, and then the package system would take responsibility for actually installing the file (and removing it when the package is uninstalled/upgraded). I'm somewhat tempted to patch our current ghc to do this, it might be easier to get that working than to get our current hacks to work properly. Duncan

2 2