- Glasgow-haskell-users

[Fwd: Re: [Gtk2hs-devel] Help with build on Alpha]
by Marco Túlio Gontijo e Silva 19 Oct '09

19 Oct '09

Hi. I sent a mail to gtk2hs-devel about this bug, and I'm forwarding it's response to here. Greetings. -------- Mensagem encaminhada -------- De: Axel Simon <Axel.Simon(a)ens.fr> (...) On Sep 27, 2009, at 18:02, Marco Túlio Gontijo e Silva wrote: (...) > I don't have a clue about this bug: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540879 . Do you have > any idea about what could be causing this? (...) This is a limitation of ghc. So you should ask the ghc people if they can fix this. Then we could think of a work-around. But the only workaround there is is not to bind functions that are affected by the limitation. That would pretty much rule out all modules in ModelView/ which is a rather important part of Gtk2Hs. (...) -- marcot http://marcot.iaaeee.org/

3 2

STM experiment
by Luca Ciciriello 14 Oct '09

14 Oct '09

Hi All. I'm very new using Concurrency and STM in Haskell. I'm trying some basic example using STM like this one: module Main where import IO import Control.Concurrent import Control.Concurrent.STM main :: IO () main = do forkIO (hPutStr stdout "Hello") hPutStr stdout " world\n" Loading this module in GHCi and running main, the result is: wHoerllldo On MacOs X 10.5.8 and on WindowsXp Compiling this module with: ghc --make Main.hs -o Main and launcing ./Main the result is just: Terminal> world Am I doing something wrong? My expected result was Hello world (or world Hello) Thanks in advance for any answer. Luca.

7 12

Attempts to install libraries with GHC 6.12.1rc1
by Neil Brown 13 Oct '09

13 Oct '09

Hi, I downloaded the new GHC release candidate. It compiled and installed first time, which was great. However, this is not true of all the libraries. I'm posting here in the hope that it helps other users trying to get it to work, or library maintainers to see what breaks in the new compiler. I know most people should wait for the Haskell platform, but I'm happy to jump through hoops to try the release candidate. So, after installing GHC, I tried to bootstrap cabal-install with the bootstrap.sh script, but that told me it required parsec and network. (I have since seen a post on this list that cabal-install won't work, but anyway....) Parsec (and mtl, which it needed) installed fine with 6.12.1-rc1. The network package said: Network/Socket.hsc:1707:45: Not in scope: data constructor `System.Posix.Internals.Stream' (I also tried the latest version of network from the darcs repository, but that said: Warning: defaultUserHooks in Setup script is deprecated. Configuring network-2.2.1.4... Warning: The 'build-type' is 'Configure' but there is no 'configure' script. Setup.hs: Missing dependency on a foreign library: * Missing header file: HsNet.h Even though HsNet.h is in the include directory already... odd. ) Anyway, it looked like that Posix module was in the unix library, so I thought I'd install that. That said: Preprocessing library unix-2.3.2.0... gcc: unrecognized option '-R/home/nccb2/lib/ghc-6.12.0.20091010/base-4.2.0.0' gcc: unrecognized option '-R/home/nccb2/lib/ghc-6.12.0.20091010/integer-gmp-0.2.0.0' gcc: unrecognized option '-R/home/nccb2/lib/ghc-6.12.0.20091010/ghc-prim-0.2.0.0' gcc: unrecognized option '-R/home/nccb2/lib/ghc-6.12.0.20091010' gcc: unrecognized option '-R/home/nccb2/lib/ghc-6.12.0.20091010' #... Above 5 lines repeated a lot of times #gcc --version is 4.3.3 Building unix-2.3.2.0... dist/build/System/Posix/Signals.hs:127:0: error: Signals.h: No such file or directory I searched for Signals.h on my file system: /home/nccb2/ghc-6.10.4/includes/Signals.h /home/nccb2/lib/ghc-6.10.4/include/Signals.h /home/nccb2/lib/ghc-6.12.0.20091010/include/rts/Signals.h /home/nccb2/ghc-6.12.0.20091010/includes/rts/Signals.h /home/nccb2/ghc-6.12.0.20091010/rts/posix/Signals.h So I tried configuring with --extra-include-dirs=/home/nccb2/lib/ghc-6.12.0.20091010/include/rts which got further, but that said: [13 of 21] Compiling System.Posix.IO ( dist/build/System/Posix/IO.hs, dist/build/System/Posix/IO.o ) System/Posix/IO.hsc:217:11: Not in scope: `haFD' System/Posix/IO.hsc:218:2: Not in scope: `flushWriteBufferOnly' System/Posix/IO.hsc:219:2: Not in scope: `unlockFile' System/Posix/IO.hsc:223:13: `haFD' is not a (visible) constructor field name These functions seem to have gone in base-4, so I changed the unix.cabal file's base-depends to base < 4. That takes away the unlockFile error, but the others remain. Which is odd, because flushWriteBufferOnly is in GHC.Handle in base-3, which System/Posix/IO.hsc imports. So now I'm stuck. Can anyone say what the fix is that I need to apply to the unix package to get it working? Thanks, Neil. P.S. parallel, stm, HUnit and QuickCheck-2 all installed fine too.

2 3

Should ghci understand this pthread library?
by Maurício CA 13 Oct '09

13 Oct '09

After using ghci to load a library I'm working in, I got this message: can't load .so/.DLL for: pthread (/usr/lib/libpthread.so: invalid ELF header) Then I did 'cat /usr/lib/libpthread.so' and, much to my surprise, it's a text file with the following contents: /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-i386) GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a ) Is this a standard file? Should ghci be able to understand it and, maybe, use the listed libraries instead? Thanks, Maurício

1 1

bug in 6.12.1-pre
by Serge D. Mechveliani 12 Oct '09

12 Oct '09

Dear GHC team, I tried ghc-6.12.0.20091010-src.tar.bz2 on Linux, Debian, i386-* And it cannot compile my Dumatel project. It fails at the segment: module Bug where compose :: [a -> a] -> a -> a compose = foldr (.) id class Compose a where compose1 :: a -> a -> a ghc -c -O Bug.hs reports /tmp/ghc29984_0/ghc29984_0.s: Assembler messages: /tmp/ghc29984_0/ghc29984_0.s:23:0: Error: symbol `Bug_compose1_closure' is already defined /tmp/ghc29984_0/ghc29984_0.s:102:0: Error: symbol `Bug_compose1_info' is already defined `-O' is essential here. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

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