- Glasgow-haskell-users

Ghci fails to load modules, but ghc compiles OK
by Colin Paul Adams 09 Oct '09

09 Oct '09

I've been using ghc 6.10.3 on 64-bit Linux to compile my application, and it runs OK, modulo bugs. I want to debug a problem, so I load it in ghci, but when i type main I get: Loading package network-2.2.1.1 ... GHCi runtime linker: fatal error: I found a duplicate definition for symbol my_inet_ntoa whilst processing object file /usr/lib64/ghc-6.10.3/network-2.2.1.1/HSnetwork-2.2.1.1.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. Why would ghci have a problem, but not ghc? -- Colin Adams Preston Lancashire

2 1

Snow Leopard GHC
by Barney Stratford 08 Oct '09

08 Oct '09

I've been trying to get GHC working for x86_64 on Snow Leopard, with a certain amount of success, but have got stuck. Maybe one of you could point me in the right direction. I now have a working compiler, but the linker in the runtime system seems to be missing some stuff. Specifically, in rts/Linker.c, there are references to X86_64_RELOC_UNSIGNED, X86_64_RELOC_SIGNED and so on, but it simply barfs when faced with a X86_64_RELOC_SIGNED_1 etc. I'd thought it would be a matter of adding a few lines of code, but everything I've tried has ended in tears. Trouble is, none of the documentation mentions X86_64_RELOC_SIGNED_1, although it does appear in C headers. It occurs only rarely in source examples, and it really isn't clear to me how I should proceed. Any ideas? Cheers, Barney.

4 14

GHC on Snow Leopard: best practices?
by David Menendez 08 Oct '09

08 Oct '09

Is there any consensus about what needs to be done to get a working ghc installation on a Snow Leopard (Mac OS X 10.6) system? The Mac OS X wiki page[1] currently links to a blog post[2] that recommends manually patching /usr/bin/ghc, but I have also seen recommendations that people patch ghci, runhaskell, runghc, and hsc2hs. Is that also recommended? If so, there should probably be an updated how-to on the wiki. I expect most Haskell users are capable of patching the scripts themselves, given instructions, but it's hardly convenient. Would it be practical to repackage the current ghc installer with updated scripts for Snow Leopard? If not, will there be updated scripts available for the forthcoming releases of GHC or the Haskell Platform? [1] http://www.haskell.org/haskellwiki/Mac_OS_X [2] http://obvioushints.blogspot.com/2009/09/running-haskell-ghc-on-snow-leopar… -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

6 6

Re: Ghci dynamic linking (Was: C++ libraries and GHCI)
by C Rodrigues 08 Oct '09

08 Oct '09

I've encountered the problem with weak symbols also, and filed a bug report against ghc (#3333). Weak symbols are used by gcc (with elf) to accommodate C++'s compilation model. In C++, it's permitted to define class methods and template code in header files. Because header files can be included in many source files, the same object code will appear in many object files. It's the linker's job to merge these definitions. There's no standard way of handling C++ linking, unfortunately, so handling weak symbols won't necessarily solve the problem for every compiler. If there will be no cross-references involving weak symbols between different .a files, such as when you have a C++ library that doesn't depend on other C++ libraries, then it should be sufficient to treat a weak defined symbol as 'defined' and a weak undefined symbol as NULL. However, I don't know if this is really a common case; most C++ code depends on libstdc++, in which case there may be multiple weak symbol definitions. --heatsink > > Thanks for the reply, Max. > > If it's not something overly complex, I'll try to hack ghc > to see if I can produce a working patch... > > probably that symbol type can be safely ignored by > ghci linker. > > Thanks again for your help > Paolo > > > On Wed, Sep 30, 2009 at 2:29 PM, Max Bolingbroke > <batterseapower(a)hotmail.com> wrote: > > (Moving to ghc-users) > > > > I'd never seen V in nm output before: > > > > """ > > The symbol is a weak object. When a weak defined symbol is linked > > with a normal defined symbol, the normal defined symbol is used with > > no error. When a weak undefined symbol is linked and the symbol is > > not defined, the value of the weak symbol becomes zero with no error. > > On some systems, uppercase indicates that a default value has been > > specified. > > """" > _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141665/direct/01/

1 0

Malformed class assertion with GHCi's output (a -> a ~ T a)
by Sean Leather 04 Oct '09

04 Oct '09

I queried (:t) the type of something in GHCi, and it told me the value should have the constraint (a -> a ~ T a) among others. When I tried to use this in code, I got a "malformed class assertion." So, I put parentheses around the function type, ((a -> a) ~ T a), and everybody is happy again. Is there something off about the precedence of (~) vs. (->)? Should GHCi print the parentheses? I'm using GHC 6.10.1, so this might already be fixed. Regards, Sean

3 2

Re: [Haskell-cafe] Ghci dynamic linking (Was: C++ libraries and GHCI)
by Max Bolingbroke 02 Oct '09

02 Oct '09

(Moving to ghc-users) I'd never seen V in nm output before: """ The symbol is a weak object. When a weak defined symbol is linked with a normal defined symbol, the normal defined symbol is used with no error. When a weak undefined symbol is linked and the symbol is not defined, the value of the weak symbol becomes zero with no error. On some systems, uppercase indicates that a default value has been specified. """" Perhaps support needs to be added for this symbol type to the GHCi dynamic linker? (It would work in compiled programs b/c we call down to the system static linker in that case). Cheers, Max 2009/9/29 Paolo Losi <paolo.losi(a)gmail.com>: > Hi all, > > I would really appreciate if anyone could > give a look to the following problem. > > Thanks in advance!!! > Paolo > > > ---------- Forwarded message ---------- > From: Paolo Losi <paolo.losi(a)gmail.com> > Date: Mon, Sep 14, 2009 at 10:33 AM > Subject: C++ libraries and GHCI > To: glasgow-haskell-users(a)haskell.org > > > Hi all, > > I'm working on a tentative implementation of haskell binding to libsvm [1]: > > http://hackage.haskell.org/package/HSvm > > The package includes libsvm C++ sources. > While it works perfectly with ghc --make (try to install the package and > compile http://bitbucket.org/pao/hsvm/raw/6cf7ca91f1e5/test/test.hs) > it fails with ghci: > > (hsvm)(env)paolo@moltrasio:~/trash$ ghci test.hs > GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Ok, modules loaded: Main. > Prelude Main> main > Loading package syb ... linking ... done. > Loading package array-0.2.0.0 ... linking ... done. > Loading package containers-0.2.0.1 ... linking ... done. > Loading package HSvm-0.1.0.2.89 ... linking ... <interactive>: > /home/paolo/trash/hsvm/lib/HSvm-0.1.0.2.89/ghc-6.10.4/HSHSvm-0.1.0.2.89.o: > unknown symbol `_ZTV6Kernel' > ghc: unable to load package `HSvm-0.1.0.2.89' > > Please note that the symbol is available in libHSHSvm-0.1.0.2.89.a > > $ nm HSHSvm-0.1.0.2.89.o |grep _ZTV6Kernel > 00000000 V _ZTV6Kernel > $ nm libHSHSvm-0.1.0.2.89.a |grep _ZTV6Kernel > 00000000 V _ZTV6Kernel > > Can anyone give a look to the problem? > > Thanks > Paolo > > [1] http://www.csie.ntu.edu.tw/~cjlin/libsvm/ > > > > -- > Paolo Losi > e-mail: paolo(a)enuan.com > mob: +39 348 7705261 > > ENUAN Srl > Via XX Settembre, 12 - 29100 Piacenza > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

2 1

which difference...
by Luca Ciciriello 30 Sep '09

30 Sep '09

Hi all. I've recently changed my home machine (MacOS X 10.5.8 intel) and I've installed the GHC 6.10.4 using the pakage: GHC-6.10.4-i386.pkg. All works fine and I can continue all my research projects on my new machine. Then I've noticed that exists another kind of installation using the package: haskell-platform-2009.2.0.2-i386.dmg. What diferences exists between these two pakages? Am I missing something using the first pakage instead using the dmg distribution? Thanks in advance for any answer. Luca. Upgrade to Internet Explorer 8 Optimised for MSN. Download Now _________________________________________________________________ With Windows Live, you can organise, edit, and share your photos. http://clk.atdmt.com/UKM/go/134665338/direct/01/

2 1

Intel's Concurrent Collections for Haskell
by Don Stewart 29 Sep '09

29 Sep '09

http://softtalkblog.wordpress.com/2009/09/29/more-about-haskell-and-intel-c… Intel involved in work to port Concurrent Collections to Haskell. Might be interesting for benchmarks on 6.12 -- Don

1 0

Re: [Haskell-cafe] Status of GHC as a Cross Compiler
by Donnie Jones 24 Sep '09

24 Sep '09

Hello John, glasgow-haskell-users is a more appropriate list... http://www.haskell.org/mailman/listinfo/glasgow-haskell-users I went ahead and cc'd your message to the list. Any replies please include John's email address as I don't think he is subscribed to the list. Hope that helps... -- Donnie Jones On Wed, Sep 23, 2009 at 1:50 PM, John Van Enk <vanenkj(a)gmail.com> wrote: > Hi, > > This may be more appropriate for a different list, but I'm having a hard > time figuring out whether or not we're getting a cross compiler in 6.12 or > not. Can some one point me to the correct place in Traq to find this > information? > > /jve > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

2 1

ANNOUNCE: GHC 6.8.3 Release Candidate
by Ian Lynagh 22 Sep '09

22 Sep '09

We are pleased to announce the Release Candidate phase for GHC 6.8.3. Snapshots beginning with 6.8.2.20080527 are release candidates for 6.8.3 You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src-extralib… Only the first of these is necessary. The "extralibs" package contains various extra packages that are often supplied with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There is also currently an installer for i386/Windows and binary distributions for x86_64/Linux and i386/Linux. More may appear later. Please test as much as possible; bugs are much cheaper if we find them before the release! We expect to release in a few days, assuming no major issues are discovered. Thanks Ian, on behalf of the GHC team

8 13