Ghci fails to load modules, but ghc compiles OK
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Snow Leopard GHC
On 08/10/2009 15:07, Barney Stratford wrote: So which compiler is generating the bogus code here? Is this the stage1 x86-64 compiler, or the i386 compiler? It's the stage1 x86_64 compiler. The problem here is that 375900174587920 doesn't even fit into 64 bits, hence the assembler's complaint. Yes, I see that. GHC keeps these values as Integers internally, so it's possible that some misconfiguration has caused it to produce a values that's out of range, although I agree that the fact that it is bigger than even 2^64 is quite suspicious. I suggest dumping out some intermediate code, e.g. -dppr-cmm -dppr-opt-cmm. If that fails to narrow it down, then you may need to add some debug traces the native code generator to find out where these values are coming from. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Snow Leopard GHC
So which compiler is generating the bogus code here? Is this the stage1 x86-64 compiler, or the i386 compiler? It's the stage1 x86_64 compiler. The problem here is that 375900174587920 doesn't even fit into 64 bits, hence the assembler's complaint. Cheers, Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Snow Leopard GHC
On 08/10/2009 10:57, Barney Stratford wrote: Latest set of problems. I've tried using the i386 build of GHC 6.10.4 to build the x86_64 version in the manner that I described in an earlier post. I'm not getting any segfaults now, but instead it says the following during make: /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal-bin /usr/bin/ghc /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 build --distpref dist-install --ghc-option=-H32m --ghc-option=-O --ghc-option=-I/sw/include --ghc-option=-L/sw/lib --ghc-option=-Wall Preprocessing executables for installPackage-1.0... Building installPackage-1.0... [1 of 1] Compiling Main ( installPackage.hs, dist-install/build/installPackage/installPackage-tmp/Main.o ) /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ghc38027_0.s:3616:0: Bignum number illegal. Absolute 0 assumed. /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ghc38027_0.s:3677:0: Bignum number illegal. Absolute 0 assumed. /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ghc38027_0.s:3709:0: Bignum number illegal. Absolute 0 assumed. etc... Looking in the assembler file, I get stuff like: Lc4a1: jmp *-16(%r13) .long _s3j4_info - _s3j4_info_dsp .text .align 3 _s3lv_info_dsp: .quad _Main_a1_srt-(_s3lv_info)+72 .quad 3 .quad 375900174587920 _s3lv_info: Lc4bb: leaq -16(%rbp),%rax cmpq %r14,%rax (That bignum is at line 3616.) Any ideas what might be causing this? Almost certainly a misconfiguration somewhere, but it's hard to tell where. Something thinks that words are 32 bits when they are in fact 64, or vice versa. So which compiler is generating the bogus code here? Is this the stage1 x86-64 compiler, or the i386 compiler? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC on Snow Leopard: best practices?
On 07/10/2009 21:58, Barney Stratford wrote: I'm back in Cambridge now. Snowdonia was great, and just as wet as expected. As far as I'm aware, nobody's got a fully functioning Snow Leopard GHC yet. Just before going away, I tried to use my partly-functioning 64-bit GHC to build 6.10, but found that the stage 1 compiler segfaulted. My plan now is to get 6.8.3 fully working so that we all have something, if a little old, that works. (This is because I need it for another project.) Once I've managed this, I'll post a full set of instructions to get everyone else going too. Then I plan to attempt to get 6.12 working, and provide a binary that can be used for bootstrapping. (I may need some pointers for this.) Incidentally, 6.12 doesn't appear to be in http://www.haskell.org/ghc/dist/ , only in the Darcs repo. Was that intentional? So far, the sticking point has been getting the interactive linker to work. Snow Leopard has much tighter security than its predecessors, so we have to use mmap. Unfortunately, the mmap version of GHC's linker also requires mremap, which is a Linux-only extension that Snow Leopard doesn't have. I believe we fixed the mremap dependency in 6.10, and that was also when we added support for libffi. I expect you'll have a much easier time getting GHCi to work with 6.10 or 6.12, so use 6.8.x for bootstrapping only. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Ghci dynamic linking (Was: C++ libraries and GHCI)
I've encountered the problem with weak symbols also, and filed a bug report against ghc (#). 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 > 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/___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Snow Leopard GHC
Latest set of problems. I've tried using the i386 build of GHC 6.10.4 to build the x86_64 version in the manner that I described in an earlier post. I'm not getting any segfaults now, but instead it says the following during make: /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal-bin /usr/bin/ ghc /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/ bootstrapping.conf 1.6.0.3 build --distpref dist-install --ghc- option=-H32m --ghc-option=-O --ghc-option=-I/sw/include --ghc-option=- L/sw/lib --ghc-option=-Wall Preprocessing executables for installPackage-1.0... Building installPackage-1.0... [1 of 1] Compiling Main ( installPackage.hs, dist-install/ build/installPackage/installPackage-tmp/Main.o ) /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ ghc38027_0.s:3616:0: Bignum number illegal. Absolute 0 assumed. /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ ghc38027_0.s:3677:0: Bignum number illegal. Absolute 0 assumed. /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ ghc38027_0.s:3709:0: Bignum number illegal. Absolute 0 assumed. etc... Looking in the assembler file, I get stuff like: Lc4a1: jmp *-16(%r13) .long _s3j4_info - _s3j4_info_dsp .text .align 3 _s3lv_info_dsp: .quad _Main_a1_srt-(_s3lv_info)+72 .quad 3 .quad 375900174587920 _s3lv_info: Lc4bb: leaq -16(%rbp),%rax cmpq %r14,%rax (That bignum is at line 3616.) Any ideas what might be causing this? Cheers, Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC on Snow Leopard: best practices?
On Thu, 2009-10-08 at 18:32 +1100, Manuel M T Chakravarty wrote: > David Menendez: > > 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. > > Patching /usr/bin/ghc is sufficient to get a version of GHC that > passes the regression tests suite in "fast" mode (the same setting > that the validate script uses). If you want to use hsc2hs, you need > to patch that, too. I haven't found a need to patch the interpreter, > though. And they almost certainly do want hsc2hs (even if they don't know it) because it's used by all sorts of other libs. The first one people hit is the zlib binding which is used by cabal-install. It appears to compile ok but then fails the version check performed by the zlib C library (eg when someone does cabal update). Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC on Snow Leopard: best practices?
David Menendez: 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. Patching /usr/bin/ghc is sufficient to get a version of GHC that passes the regression tests suite in "fast" mode (the same setting that the validate script uses). If you want to use hsc2hs, you need to patch that, too. I haven't found a need to patch the interpreter, though. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
