- Glasgow-haskell-users

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

10 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 07 Sep '11

07 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

Re: Parallel --make (GHC build times on newer MacBook Pros?)
by Evan Laforge 05 Sep '11

05 Sep '11

> Ah, but you're measuring the startup time of ghc --make, which is not the same as the work that each individual ghc would do if ghc were invoked separately on each module, for two reasons: Excellent, sign me up for this plan then :) ghc on a single file is very quick.

1 0

GHC build times on newer MacBook Pros?
by Johan Tibell 05 Sep '11

05 Sep '11

Hi! I'm looking to upgrade my laptop so that I can (among other things) compile GHC faster. I'll either get the 13" 2.7GHz dual-core Intel Core i7 model or the 15" 2.2GHz quad-core Intel Core i7 model. Anyone know if it's worth to get the 15" model? According to these benchmarks it should be quite a bit faster: http://www.primatelabs.ca/geekbench/mac-benchmarks/ but I don't know if I can get enough parallelism out of GHC's build to use all 4 cores in the 15" model. -- Johan

11 23

Superclass defaults
by Simon Peyton-Jones 05 Sep '11

05 Sep '11

(Adding GHC users, and changing title.) | Conor McBride wrote: | > http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances | > I don't know if it's likely to be implemented in GHC anytime soon,.. | > So things are looking up. It should soon be technically feasible to | > separate the issues of whether the Monoid operator should be (<>) and | > whether it should actually live in a Semigroup superclass... | | Nice. But will it be happening soon, or not? And how soon is | soon? Not soon enough to be useful for this mappend question. But, concerning proposed extensions to GHC about class aliases/superclass defaults etc, the truth is that the biggest reason for inertia here at GHC HQ is not so much the implementation effort (athough that is always an issue). Rather, it's uncertainty about (a) Is there a reasonably large group of users who really want such a change? Or is it just "nice to have"? (b) What is the "right" design? (c) Does it pay its way? (ie do the programming benefits justify the cost in terms of both language complexity and ongoing maintenance burden of one more feature to bear in mind when changing anything) With help from Conor we have made some progress on this: we have a draft design: http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances If you care about the issue, maybe you can help resolve the above questions. In particular, to give concrete evidence for (b), working out some case studies would be a Good Thing. The examples given in other proposals using the extension proposed here would be one starting point. If someone felt able to act as moderator for the discussion, willing to summarise conclusions, open questions, and so on, on the wiki page, that would be enormously helpful. I am in too many inner loops. But I *am* willing to contemplate such an extension -- it has the same flavour as default methods themselves, which are a very useful part of H98. Simon

14 28

Panic when using syb with GHC API
by Simon Hengel 01 Sep '11

01 Sep '11

Hello, I'm trying to query a type-checked module with syb, this works for a plain binding. But as soon as I add a type signature for that binding, I get an "panic!" I experienced similar problems with a renamed module. Are those data structures meant to be used with syb? And if yes, what did I miss? Bellow is some code to reproduce my issue. Any help is very much appreciated. -- A.hs module Main where import GHC import Outputable import Data.Generics import GHC.Paths (libdir) import Bag main :: IO () main = do m <- parse putStrLn $ showSDoc $ ppr $ m putStrLn "\n---\n" putStrLn $ showSDoc $ ppr $ selectAbsBinds m parse = runGhc (Just libdir) $ do _ <- getSessionDynFlags >>= setSessionDynFlags target <- guessTarget "B.hs" Nothing setTargets [target] Succeeded <- load LoadAllTargets modSum <- getModSummary $ mkModuleName "B" m <- parseModule modSum >>= typecheckModule return $ typecheckedSource m selectAbsBinds :: GenericQ [HsBindLR Id Id] selectAbsBinds = everything (++) ([] `mkQ` f) where f x@(AbsBinds _ _ _ _ _) = [x] f _ = [] -- B.hs module B where foo :: Char foo = 'f' Cheers, Simon

6 8