September 2011 - Glasgow-haskell-users

error building GHC Head
by Greg Weber 15 Sep '11

15 Sep '11

I just cloned GHC from github and tried to build it for the first time. I get the below result where the build tool says that existing object files are missing. I haven't touched a Makefile in a long time- help here is very appreciated. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -H32m -O -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -split-objs -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -no-user-package-conf -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/CString.hs -o libraries/ghc-prim/dist-install/build/GHC/CString.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__1.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/.o::CString(void) /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__3.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__4.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__5.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__6.o collect2: ld returned 1 exit status make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/CString.o] Error 1 make: *** [all] Error 2

1 1

Re: [Haskell-cafe] Undefined symbol error coming from shared, dynamic library.
by Captain Freako 14 Sep '11

14 Sep '11

Hi Sergiy, *>I thought having static library to solve my problem. And I'm looking for how to build static library, but no luck. * I was also, originally trying to build a shared *static* library. (I wanted to distribute a plug-in, which could be used by people knowing nothing about Haskell working on machines that did not have the Haskell Platform installed.) Then, I happened across this nugget in section 4.11.3 of the GHC 6.12.3 User's Guide<file:///usr/share/doc/ghc6-doc/html/users_guide/using-shared-libs.html#id2620284> : In principle you can use -shared without -dynamic in the link step. That > means to statically link the rts all the base libraries into your new shared > library. This would make a very big, but standalone shared library. Indeed > this is exactly what we must currently do on Windows where -dynamic is not > yet supported (see Section 11.6, “Building and using Win32 DLLs ”). On > most platforms however that would require all the static libraries to have > been built with -fPIC so that the code is suitable to include into a > shared library and we do not do that at the moment. > That is when I changed strategies and started trying to make a shared * dynamic* version of my library work. *A question to the group: *With regard to: "... that would require all the static libraries to have been built with -fPIC ...", is this something I can do myself by re-cabaling with the proper options set in my *~/.cabal/config* file, or is this more involved than that? Thanks, -db On Sun, Sep 11, 2011 at 8:55 AM, Sergiy Nazarenko < nazarenko.sergiy(a)gmail.com> wrote: > Hi, Captain, > > As far as I see you try to build static library. > If this correct, what did not work in static library? > Why do you decide compile with -dynamic option? > > I was trying to build shared library. Other python library has used > some functions from library which I had written using Haskell. But > some software which we use in my company had crached after attempts to > import python module. Under pure python it works OK, but software has > crached. I thought having static library to solve my problem. And I'm > looking for how to build static library, but no luck. > > Cheers, > Sergiy > > On 11 September 2011 17:56, Captain Freako <capn.freako(a)gmail.com> wrote: > > Sergiy, Tom, > > > > Thanks for your replies. > > > > Sergiy, I was able to get this working without having to recompile my > > installed Haskell libraries. > > > > Tom, you were correct; I needed to explicitly link against the Haskell > > run-time system, as well as a few other things: > > > > I changed my ghc link options from this: > > > > HC_LOPTS = -no-hs-main -shared -package parsec -package dsp -static > > > > to this: > > > > HC_LOPTS = -shared -dynamic -package parsec-3.1.1 -package dsp -lHSrts > > -L/usr/lib/ghc-6.12.3/ -lm -lffi -lrt > > > > and things are working. > > > > (The command that builds my mixed language, shared object library, > > `libami.so', is: > > > > ghc -o libami.so $(HC_LOPTS) {object files, compiled from both C and > Haskell} > > ) > > > > I can understand why I'd have to explicitly link against `libHSrts', > > since I'm asking ghc for a shared object library and not an > > executable. However, I'm not sure about the following: > > - Why do I need to give the `-L/usr/lib/ghc-6.12.3/' option? (It seems > > like ghc ought to know about that, implicitly.) > > - Why do I need to explicitly link against the 3 standard C libraries: > > `m', `ffi', and `rt'? (I've never needed to do this, previously, when > > I was building/testing this project statically.) > > > > Thanks, in advance, for any insights! > > > > -db > > > > > > On 9/10/11, Sergiy Nazarenko <nazarenko.sergiy(a)gmail.com> wrote: > >> I've recompiled my library again and now it works without any problem. > >> Probably I made mistake somewhere. > >> > >> Cheers, > >> Sergiy > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe(a)haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > >

1 0

Type of a self build let expression
by Sven Urbanski 12 Sep '11

12 Sep '11

Hi ghc-users, I'm having trouble reconstructing a specific let expression. Let's assume we have the following file Main.hs: module Main where data HList b = Null | Node b (HList b) foo2 :: e -> Int foo2 n = len (pow Null (42::Int)) len :: HList a -> Int len Null = 0 pow :: HList a -> a -> HList a pow h x = h Now I can calculate the type in ghci: :t let (_,x) = (pow x (42::Int), Null) in x which prints: let (_,x) = (pow x (42::Int), Null) in x :: HList Int or short: HList Int This is exactly what I need. Note that this is not the same as :t let x = Null in x The type of x depends on the context. Or in other words: I want to know the most general type of a parameter of a function when all other parameters of that function are given. So I wrote a function to create such a LetExpr with the ghc api. Then I can calculate the type of the LetExpr. My function returns some let expr but the result of the calculation of the type is different. The resulting type of my function is always: HList b. The problem is, during construction I have to give the variable "x" a type, which in this case is "HList b". It seems that to create a HsVar I already need to know the type of the HsVar (but I don't, that's kind of the purpose of the function). How can i calculate the type like in ghci? I am using ghc 6.12.3. I would very much appreciate any help. The rest of this mail contains the functions that I use to create the LetExpr. Thanks, Sven makeLocalVar :: Type -> Unique -> OccName -> Id makeLocalVar t u occn = mkLocalVar VanillaId (mkSystemName u occn) t vanillaIdInfo replaceFirstParam :: HsExpr Id -> HsExpr Id -> HsExpr Id replaceFirstParam (HsApp (L noSrcSpan (HsApp l1 r1)) r2) param = HsApp (noLoc $ HsApp l1 (noLoc param)) r2 replaceFirstParam (HsApp l r) param = HsApp l (noLoc param) replaceFirstParam f x = error ("unknown type for replaceFirstParam!" ++ showOutputable f) makeLetExpr :: HsExpr Id -> HsExpr Id -> DsM (HsExpr Id) makeLetExpr e@(HsVar id) parent = trace ("let parent: " ++ showOutputable parent ++ "; expr: " ++ showOutputable e) $ do supply <- getUniqueSupplyM typeX <- hsExpr2TypeDo e let uniqName = uniqFromSupply supply :: Unique -- the let construct: hslet = HsLet locbinds lhsExpr lhsExpr = noLoc hsExpr :: LHsExpr Id -- the very right side of the let (the part after 'in') ... hsExpr = HsVar locVarX :: HsExpr Id -- is "the_x"! locVarX = makeLocalVar typeX uniqName occnX :: Id occnX = mkVarOcc "x" :: OccName locVarUndef= makeLocalVar typeUndef uniqName occn_ :: Id occn_ = mkVarOcc "underscore" :: OccName -- right side of the expr (e.g. '(pow x, bar Null)'): rhs_ = L noSrcSpan _expr :: LHsExpr Id rhsX = L noSrcSpan xexpr :: LHsExpr Id _expr = replaceFirstParam parent hsExpr :: HsExpr Id xexpr = e :: HsExpr Id -- the_x = xyz vbindUndef = VarBind locVarUndef rhs_ :: HsBindLR Id Id vbindX = VarBind locVarX rhsX :: HsBindLR Id Id locbinds = bt :: HsLocalBinds Id bt = HsValBinds lr :: HsLocalBindsLR Id Id recflag = NonRecursive :: RecFlag lhsbinds = listToBag [noLoc vbindX] :: LHsBinds Id lhsbinds2 = listToBag [noLoc vbindUndef] :: LHsBinds Id lr = ValBindsOut [(recflag, lhsbinds2), (recflag, lhsbinds)] [] :: HsValBindsLR Id Id typeUndef = error "dont know the type!" return $ trace ("let replace:" ++ showOutputable _expr ++ "\nlet res:" ++ showOutputable hslet) $ hslet hsExpr2TypeDo :: HsExpr Id -> DsM Type hsExpr2TypeDo hsexpr = do let ioCoreE = dsExpr hsexpr x <- ioCoreE return (exprType x)

1 0

Re: Undefined symbol error coming from shared, dynamic library.
by Captain Freako 11 Sep '11

11 Sep '11

Sergiy, Tom, Thanks for your replies. Sergiy, I was able to get this working without having to recompile my installed Haskell libraries. Tom, you were correct; I needed to explicitly link against the Haskell run-time system, as well as a few other things: I changed my ghc link options from this: HC_LOPTS = -no-hs-main -shared -package parsec -package dsp -static to this: HC_LOPTS = -shared -dynamic -package parsec-3.1.1 -package dsp -lHSrts -L/usr/lib/ghc-6.12.3/ -lm -lffi -lrt and things are working. (The command that builds my mixed language, shared object library, `libami.so', is: ghc -o libami.so $(HC_LOPTS) {object files, compiled from both C and Haskell} ) I can understand why I'd have to explicitly link against `libHSrts', since I'm asking ghc for a shared object library and not an executable. However, I'm not sure about the following: - Why do I need to give the `-L/usr/lib/ghc-6.12.3/' option? (It seems like ghc ought to know about that, implicitly.) - Why do I need to explicitly link against the 3 standard C libraries: `m', `ffi', and `rt'? (I've never needed to do this, previously, when I was building/testing this project statically.) Thanks, in advance, for any insights! -db On 9/10/11, Sergiy Nazarenko <nazarenko.sergiy(a)gmail.com> wrote: > I've recompiled my library again and now it works without any problem. > Probably I made mistake somewhere. > > Cheers, > Sergiy > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

2 1

Undefined symbol in shared dynamic library?
by Captain Freako 09 Sep '11

09 Sep '11

Hi all, I'm trying to build a shared, dynamic library for use with a C program. I'm getting an `undefined symbol' error, when I try to run that C program, and was hoping that the last line in the output, below, might mean something to someone. I include the entire output of a `make rebuild' command, below, hoping that, maybe, I just have my command line options a little wrong. Thanks! -db dbanas@dbanas-eeepc:~/prj/haskell/AMIParse/trunk$ make rebuild make clean make[1]: Entering directory `/home/dbanas/prj/haskell/AMIParse/trunk' rm -f *.hi *.o *.out ami_test *.so make[1]: Leaving directory `/home/dbanas/prj/haskell/AMIParse/trunk' make all make[1]: Entering directory `/home/dbanas/prj/haskell/AMIParse/trunk' gcc -I/usr/lib/ghc-6.12.3/include/ -g -fPIC -c -o ami_test.o ami_test.c gcc -rdynamic -o ami_test ami_test.o -ldl ghc -c ApplicativeParsec.hs -cpp -package parsec-3.1.1 -package dsp -dynamic -fPIC ghc -c AMIParse.hs -cpp -package parsec-3.1.1 -package dsp -dynamic -fPIC ghc -c ExmplUsrModel.hs -cpp -package parsec-3.1.1 -package dsp -dynamic -fPIC ghc -c AMIModel.hs -cpp -package parsec-3.1.1 -package dsp -dynamic -fPIC gcc -I/usr/lib/ghc-6.12.3/include/ -g -fPIC -c -o ami_model.o ami_model.c rm -f libami.so ghc -o libami.so -shared -dynamic -package parsec-3.1.1 -package dsp AMIParse.o AMIModel.o ami_model.o AMIModel_stub.o ApplicativeParsec.o ExmplUsrModel.o make[1]: Leaving directory `/home/dbanas/prj/haskell/AMIParse/trunk' dbanas@dbanas-eeepc:~/prj/haskell/AMIParse/trunk$ ./ami_test test.ami /usr/lib/ghc-6.12.3/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0-ghc6.12.3.so: undefined symbol: stg_newByteArrayzh

1 0

Fwd: [Haskell-cafe] Undefined symbol error coming from shared, dynamic library.
by capn.freako＠gmail.com 09 Sep '11

09 Sep '11

-db ----- Forwarded message ----- From: "Thomas Schilling" <nominolo(a)googlemail.com> Date: Thu, Sep 8, 2011 12:37 pm Subject: [Haskell-cafe] Undefined symbol error coming from shared, dynamic library. To: "David Banas" <dbanas(a)banasfamily.net> Cc: <haskell-cafe(a)haskell.org>, <capn.freako(a)gmail.com> stg_newByteArrayzh is defined in the runtime system. Presumably you need to link against the GHC runtime system. If that doesn't help try asking your question on the glasgow-haskell-users(a)haskell.org mailing list. On 6 September 2011 16:52, David Banas <dbanas(a)banasfamily.net> wrote: > Hi all, > > I'm trying to build a shared, dynamic library for use with a C program. > I'm getting an `undefined symbol' error, when I try to run that C > program, > and was hoping that the last line in the output, below, might mean > something to someone. > I include the entire output of a `make rebuild' command, below, hoping > that, maybe, I just have my command line options a little wrong. > > Thanks! > -db > > dbanas@dbanas-eeepc:~/prj/haskell/AMIParse/trunk$ make rebuild > make clean > make[1]: Entering directory `/home/dbanas/prj/haskell/AMIParse/trunk' > rm -f *.hi *.o *.out ami_test *.so > make[1]: Leaving directory `/home/dbanas/prj/haskell/AMIParse/trunk' > make all > make[1]: Entering directory `/home/dbanas/prj/haskell/AMIParse/trunk' > gcc -I/usr/lib/ghc-6.12.3/include/ -g -fPIC -c -o ami_test.o > ami_test.c > gcc -rdynamic -o ami_test ami_test.o -ldl > ghc -c ApplicativeParsec.hs -cpp -package parsec-3.1.1 -package dsp > -dynamic -fPIC > ghc -c AMIParse.hs -cpp -package parsec-3.1.1 -package dsp -dynamic > -fPIC > ghc -c ExmplUsrModel.hs -cpp -package parsec-3.1.1 -package dsp -dynamic > -fPIC > ghc -c AMIModel.hs -cpp -package parsec-3.1.1 -package dsp -dynamic > -fPIC > gcc -I/usr/lib/ghc-6.12.3/include/ -g -fPIC -c -o ami_model.o > ami_model.c > rm -f libami.so > ghc -o libami.so -shared -dynamic -package parsec-3.1.1 -package dsp > AMIParse.o AMIModel.o ami_model.o AMIModel_stub.o ApplicativeParsec.o > ExmplUsrModel.o > make[1]: Leaving directory `/home/dbanas/prj/haskell/AMIParse/trunk' > dbanas@dbanas-eeepc:~/prj/haskell/AMIParse/trunk$ ./ami_test test.ami > /usr/lib/ghc-6.12.3/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0-ghc6.12.3.so: > undefined symbol: stg_newByteArrayzh > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Push the envelope. Watch it bend.

1 0

RE: [Template-haskell] change in [d| |] and creating instances in template-haskell 2.7
by Simon Peyton-Jones 08 Sep '11

08 Sep '11

[Redireting to ghc users; the TH list is pretty dormant and I keep thinking I should close it down altogether.] Jeremy Actually this is by design. See the long thread at http://hackage.haskell.org/trac/ghc/ticket/5375 When you say | inferBar typeName = | do s <- [d| bar _ = "sucker" | |] you are asking for a *new* definition bar _ = "sucker". But in an instance declaration you have to mention the *existing* method name. To put it another way, do you expect this to work? do { bar_nm <- newName "bar" ; return (InstanceD [] <type> [FunD bar_nm <rhs>]) } where you make up a *fresh name* (whose string-name is "bar") and use it in an instance declaration binding. I suppose you could argue that for the odd case of instance decls, TH should ignore the exact identity of the method name, and just use its string name. It would be convenient; but another weirdness too. User advice welcome! Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell- | bounces(a)haskell.org] On Behalf Of Jeremy Shaw | Sent: 07 September 2011 20:50 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] change in [d| |] and creating instances in template- | haskell 2.7 | | Hello, | | I have some code that likes like this, which works in template-haskell | 2.5 / GHC 7.0.3: | | --------------- | {-# Language TemplateHaskell, TypeFamilies #-} | module Show where | | import Language.Haskell.TH | | class Bar a where | bar :: a -> String | | inferBar :: Name -> Q [Dec] | inferBar typeName = | do s <- [d| bar _ = "sucker" | |] | d <- instanceD (return []) (appT (conT ''Bar) (conT typeName)) | (map return s) | return [d] | | ----------------- | | $(inferBar ''Bool) | | But, in template-haskell 2.6 / GHC 7.2.1, I get an error, | | Warning: No explicit method nor default method for `bar' | In the instance declaration for `Bar Bool' | | Comparing the output of -ddump-splices we see in GHC 7.0.3/ TH 2.5, we | have: | | bar-test.hs:1:1: Splicing declarations | inferBar 'Bool | ======> | bar-test.hs:4:3-17 | instance Bar Bool where | { bar _ = "sucker" } | | But in GHC 7.2.1 / TH 2.6 we have: | | bar-test.hs:1:1: Splicing declarations | inferBar 'Bool | ======> | bar-test.hs:4:3-17 | instance Bar Bool where | { bar_acAU _ = "sucker" } | | The difference being that instead 'bar' we have 'bar_acAU'. So maybe | that is why it can't find the method 'bar' in the instance | declaration? Though, I would kind of expect an error like, | | `bar_acAU' is not a (visible) method of class `Bar'. | | Am I doing something wrong? Should I file a bug ? | | Thanks! | | - jeremy | | | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

2 3

secret of light-weight user thread
by Kazu Yamamoto 08 Sep '11

08 Sep '11

Hello, Recently I exchanged information about user threads with Ruby community in Japan. The user threads of Ruby 1.8 are heavy weight and Ruby 1.9 switched to kernel threads. The reason why user threads of Ruby 1.8 are heavy weight is *portability*. Since Ruby community does not want to prepare assembler to change stack pointers for each supported CPU architecture, Ruby 1.8 copies the stack of user threads on context switch. Because I need to explain why the user threads of GHC are light weight, I gave a look at GHC's source code and found the loadThreadState function in compiler/codeGen/StgCmmForeign.hs. In this function, the stack pointer is changed in the Cmm level. So, my interpretation is as follows: Since GHC has Cmm backend, it is easy to provide assembler to change stack pointers for each supported CPU architecture. That's why GHC can provide light weight user threads. Is my understanding correct? Thanks in advance. --Kazu

2 4

ghc-mtl and ghc-7.2.1
by José Romildo Malaquias 07 Sep '11

07 Sep '11

Hello. In order to compile ghc-mtl-1.0.1.0 (the latest released version) with ghc-7.2.1, I would apply the attached patch, which removes any references to WarnLogMonad. ghc-7.2.1 does not have the monad WarnLogMonad anymore. As I do not know the details of the GHC api, I am not sure if this is enough to use ghc-mtl with ghc-7.2.1. I want ghc-mtl in order do build lambdabot. Any thoughts? Romildo

2 1

Inliner non-termination
by Ron Alford 06 Sep '11

06 Sep '11

>From the known bugs (http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs-ghc) """GHC's inliner can be persuaded into non-termination using the standard way to encode recursion via a data type... We have never found another class of programs, other than this contrived one, that makes GHC diverge, and fixing the problem would impose an extra overhead on every compilation. So the bug remains un-fixed.""" There are now three more examples, at least two of which weren't 'contrived': http://hackage.haskell.org/trac/ghc/ticket/5448 http://hackage.haskell.org/trac/ghc/ticket/5400 http://hackage.haskell.org/trac/ghc/ticket/3872 It took me about 4-6 hours to track down this bug in my own code (#5448) since it required repeatedly bisecting a larger program until I had a small testcase. In the test program, I can get around it with {-# NOINLINE funcEq #-}. In the program it came from, though, FuncEq is an imported value, so I have to either compile with -O0, or change put the pragma in the imported library, where it will effect a fair amount of code that /doesn't/ hit this bug. If adding the check is too expensive, can the inliner have a configurable recursion bount (ala -fcontext-stack)? -Ron Alford

2 2