Problems linking code from the book Haskell School of Expression

Greetings. Yesterday I decided to try some of the code in Paul Hudak's book The Haskell School of Expression. I am having problems when I do ghc --make of the code on page 40 of the book, which is the first graphics program therein. I am running OS X Snow Leopard, with the Haskell Platform (32 bit), ghc version 7.0.3. I am very green when it comes to looking under the covers at what gcc, ld, etc do at the behest of ghc. This is where things seem to go wrong, as I outline below. In setting up to try this code I discovered that I needed to install the package soegtk to get Graphics.SOE.Gtk. The cabal install of soegtk was not smooth: it appears to me that cabal does not always handle dependencies as one would hope. However, I eventually got soegtk and the packages upon which it depends installed. Here is my list of local user packages as reported by ghc-pkg: cairo-0.12.2 gio-0.12.2 glib-0.12.2 gtk-0.12.2 pango-0.12.2 soegtk-0.12.1 Oddly, in the course of running cabal install to get the above packages, at some point I got a flurry of messages similar to the one below. (This is not one of the actual messages from cabal install; I did not keep those. This warning message is from the ghc --make step, as described below.) ld: warning: ignoring file /opt/local/lib/libgtk-x11-2.0.dylib, file was built for unsupported file format which is not the architecture being linked (i386) This puzzled me, and the same thing came up at a later stage, as I shall describe shortly. But initially I ignored the messages and proceeded to try to make my sample program. Here is the code from Hudak's book, which I put in Main.hs: module Main where import Graphics.SOE.Gtk main = runGraphics ( do w <- openWindow "SOE First Try" (300,300) drawInWindow w (text (100,100) "Hello Graphics World") k <- getKey w closeWindow w ) When I do ghc --make Main, it grinds forever at the link stage. The link fails. It also gives ld warnings about ignoring libraries in /opt/local/lib, as in the example above. Then, the link eventually fails because of a huge number of unresolved symbols. Here is a sample link error from the verbose output: Undefined symbols for architecture i386: "_cairo_arc", referenced from: _sbnE_info in libHSsoegtk-0.12.1.a(Gtk.o) _se2n_info in libHSsoegtk-0.12.1.a(Gtk.o) _sf5B_info in libHSsoegtk-0.12.1.a(Gtk.o) _svSr_info in libHScairo-0.12.2.a(Paths.o) _swiH_info in libHScairo-0.12.2.a(Paths.o) "_cairo_arc_negative", referenced from: _seqb_info in libHSsoegtk-0.12.1.a(Gtk.o) _svPR_info in libHScairo-0.12.2.a(Paths.o) _swg7_info in libHScairo-0.12.2.a(Paths.o) and on and on. I have no idea what is happening here. First, I don't know whether the linker messages about ignoring libs in /opt/local/lib is connected with the unresolved symbols, but one would suspect that it is. Second, it is not clear to me why ghc would link against anything in /opt/local/lib, which it clearly does. Here are the first couple of lines of verbose output from ghc --make, showing the inclusion of the flag -L/opt/local/lib: /Developer/usr/bin/gcc -v -o Main -march=i686 -m32 -fno-stack-protector -DDONT_WANT_WIN32_DLL_SUPPORT Main.o -L/Users/Philippe/Library/Haskell/ghc-7.0.3/lib/soegtk-0.12.1/lib -L/Library/Haskell/ghc-7.0.3/lib/stm-2.2.0.1/lib -L/Users/Philippe/Library/Haskell/ghc-7.0.3/lib/gtk-0.12.2/lib -L/opt/local/lib -L/Users/Philippe/Library/Haskell/ghc-7.0.3/lib/pango-0.12.2/lib I have plenty of macports stuff installed in /opt/local. But I have not intentionally included /opt/local/lib in any path. That is, I do NOT have, for example, LD_LIBRARY_PATH or DYLD_LIBRARY_PATH set. So is it normal for ghc to link against /opt/local/lib libraries, or is it something in my environment that is triggering this? And, in any case, is that why the link fails? What about the references to "architecture i386"? Do they provide the necessary clue for the clueless (me)? Any help is appreciated. - Phil -

On Fri, Nov 25, 2011 at 12:16, Philippe Sismondi
ld: warning: ignoring file /opt/local/lib/libgtk-x11-2.0.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
Was the MacPorts gtk2 port built +universal? ("port installed gtk2", see if what it prints includes "+universal".) SL on most modern Macs builds 64-bit by default, whereas the ghc stuff in MacPorts is 32-bit only. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On 2011-11-25, at 1:28 PM, Brandon Allbery wrote:
On Fri, Nov 25, 2011 at 12:16, Philippe Sismondi
wrote: ld: warning: ignoring file /opt/local/lib/libgtk-x11-2.0.dylib, file was built for unsupported file format which is not the architecture being linked (i386) Was the MacPorts gtk2 port built +universal? ("port installed gtk2", see if what it prints includes "+universal".) SL on most modern Macs builds 64-bit by default, whereas the ghc stuff in MacPorts is 32-bit only.
I guess I did not supply enough info. I don't see why the architecture of macports stuff would make a difference. I should perhaps have said in the original post that I have no macports haskell software installed. I am not using the macports haskell-platform port. I am using the OS X Haskell Platform package downloaded from the web: Haskell Platform 2011.2.0.1-i386.pkg. To answer your question, though, here is the gtk2 macports info:
port installed gtk2 The following ports are currently installed: gtk2 @2.24.4_0+x11 gtk2 @2.24.8_1+x11 (active)
Why is ghc linking against anything installed by macports, i.e. libs in /opt/local/lib? Why would the flag -L/opt/local/lib be in the link step of ghc --make? Is this usual for ghc, or is it more likely something in my setup? Here are the library directories installed in ~/Library/Haskell/ghc-7.0.3/lib. Shouldn't ghc just link against these? cairo-0.12.2 gio-0.12.2 glib-0.12.2 gtk-0.12.2 gtk2hs-buildtools-0.12.1 pango-0.12.2 soegtk-0.12.1
-- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On Fri, Nov 25, 2011 at 14:08, Philippe Sismondi
I don't see why the architecture of macports stuff would make a difference. I should perhaps have said in the original post that I have no macports haskell software installed. I am not using the macports haskell-platform port. I am using the OS X Haskell Platform package downloaded from the web: Haskell Platform 2011.2.0.1-i386.pkg. To answer your question, though, here is the gtk2 macports info:
So, where did you get the gtk2hs stuff then? Your SOE is clearly the gtk2hs version, and gtk2hs was evidently built against MacPorts. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On 2011-11-25, at 2:29 PM, Brandon Allbery wrote:
On Fri, Nov 25, 2011 at 14:08, Philippe Sismondi
wrote: I don't see why the architecture of macports stuff would make a difference. I should perhaps have said in the original post that I have no macports haskell software installed. I am not using the macports haskell-platform port. I am using the OS X Haskell Platform package downloaded from the web: Haskell Platform 2011.2.0.1-i386.pkg. To answer your question, though, here is the gtk2 macports info: So, where did you get the gtk2hs stuff then? Your SOE is clearly the gtk2hs version, and gtk2hs was evidently built against MacPorts.
I got everything using cabal-install. It did not work smoothly at first. I did: cabal install soegtk but this reported errors and suggested that I must first do cabal install gtk2hs-buildtools I did this. The above delivered some utility executables. I made these available on my PATH, and then did cabal install soegtk Your suggestion reminds me that installing soegtk caused an outpouring of messages about "ignoring libraries". So the problem may well have arisen at that point. I should probably look at the cabal packages for gtk2hs, or maybe contact the guys who put it together. Actually, it is high time that I bite the bullet and learn about cabal internals anyway. I just HATE that kind of thing. I can hardly estimate the amount of time I have spent fighting with package management and library stuff in Common Lisp and other languages that live in a less than robust online echosystem. Thanks for your help. I'll dig into the cabal side of gtk2hs. - Phil -
-- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On Fri, Nov 25, 2011 at 15:33, Philippe Sismondi
Your suggestion reminds me that installing soegtk caused an outpouring of messages about "ignoring libraries". So the problem may well have arisen at that point. I should probably look at the cabal packages for gtk2hs, or maybe contact the guys who put it together.
Ok, then what happened is that gtk2hs found the MacPorts Gtk+ libraries, which were built native/64-bit, and tried to use them in your 32-bit GHC environment. (gtk2hs does *not* come with Gtk+ libraries; you have to provide them from somewhere.) So, either you need to find some prebuilt 32-bit Gtk+ libraries, or you need to rebuild the MacPorts libraries to be +universal so they have been 32- and 64-bit variants. That said, the latter will probably fail with missing symbols related to iconv (MacPorts' iconv library is not compatible with Apple's, which is used by the Haskell Platform build). -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On 2011-11-25, at 3:53 PM, Brandon Allbery wrote:
On Fri, Nov 25, 2011 at 15:33, Philippe Sismondi
wrote: Your suggestion reminds me that installing soegtk caused an outpouring of messages about "ignoring libraries". So the problem may well have arisen at that point. I should probably look at the cabal packages for gtk2hs, or maybe contact the guys who put it together. Ok, then what happened is that gtk2hs found the MacPorts Gtk+ libraries, which were built native/64-bit, and tried to use them in your 32-bit GHC environment. (gtk2hs does *not* come with Gtk+ libraries; you have to provide them from somewhere.)
So, either you need to find some prebuilt 32-bit Gtk+ libraries, or you need to rebuild the MacPorts libraries to be +universal so they have been 32- and 64-bit variants. That said, the latter will probably fail with missing symbols related to iconv (MacPorts' iconv library is not compatible with Apple's, which is used by the Haskell Platform build).
Thanks. I am totally unfamiliar with gtk. I has assumed that the library installed by cabal was self-contained. Call me naive.... As you suggested I installed a macports universal variant of gtk2. But it appears to me that their may be a broader problem, i.e. that I may need to install universal versions of quite a few macports libraries. I still cannot build gtk2hs without references to ignoring libraries, and then my sample program will not link. I may have to go through and install a bunch of macports universals, but in the meanwhile I tried installing the 64-bit version of the Haskell Platform. That installation fails, but does leave a 64-bit version of the ghc framework in the library. I posted a message about it on the haskell-cafe list, because this too takes me out of my depth. Even with the broken installation of 64-bit ghc I get far fewer error messages when I try to use soegtk with it. It does indeed complain about iconv symbols; whether that could be remedied is academic if I cannot get a clean installation of 64-bit ghc, since I have no idea what is broken in 64-bit After exchanging posts with you I surfed the web a bit, and came to the conclusion that architecture is something of a problem for quite a few OS X users of ghc. Is that fair to say?
-- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On Fri, Nov 25, 2011 at 19:41, Philippe Sismondi
After exchanging posts with you I surfed the web a bit, and came to the conclusion that architecture is something of a problem for quite a few OS X users of ghc. Is that fair to say?
Yes. For a long time there wasn't a 64-bit GHC at all, and it still throws a number of warnings and occasional other fits (especially on Lion where Apple changed the linker yet again, but you're on SL so that at least shouldn't matter). Also, the HP stuff doesn't play along with MacPorts very well, and MacPorts' own HP is even older than Debian stable. Looks like your best bet is to temporarily move /opt/local out of the way and then follow the directions at http://live.gnome.org/GTK%2B/OSX/Building#Prerequisites to build native Gtk+ libraries. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On 2011-11-25, at 7:54 PM, Brandon Allbery wrote:
On Fri, Nov 25, 2011 at 19:41, Philippe Sismondi
wrote: After exchanging posts with you I surfed the web a bit, and came to the conclusion that architecture is something of a problem for quite a few OS X users of ghc. Is that fair to say? Yes. For a long time there wasn't a 64-bit GHC at all, and it still throws a number of warnings and occasional other fits (especially on Lion where Apple changed the linker yet again, but you're on SL so that at least shouldn't matter). Also, the HP stuff doesn't play along with MacPorts very well, and MacPorts' own HP is even older than Debian stable.
Looks like your best bet is to temporarily move /opt/local out of the way and then follow the directions at http://live.gnome.org/GTK%2B/OSX/Building#Prerequisites to build native Gtk+ libraries.
Well, I just realized that since I only need this for learning purposes (not production code) I may as well do it under linux. I have my linux box on a kvm with the mac. (That's my current form of "virtualization" ;-) I'll do this if ubuntu and HP work well together. Thoughts?
-- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On Fri, Nov 25, 2011 at 22:30, Philippe Sismondi
Well, I just realized that since I only need this for learning purposes (not production code) I may as well do it under linux. I have my linux box on a kvm with the mac. (That's my current form of "virtualization" ;-) I'll do this if ubuntu and HP work well together. Thoughts?
That's where I've ended up for my xmonad development (well, still setting it up), since xmonad is crashing when I use a ghc that is built against MacPorts (both MP's own GHC and a locally built up to date haskell-platform) which I need for X11-xft :/ -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On 2011-11-25, at 10:53 PM, Brandon Allbery wrote:
On Fri, Nov 25, 2011 at 22:30, Philippe Sismondi
wrote: Well, I just realized that since I only need this for learning purposes (not production code) I may as well do it under linux. I have my linux box on a kvm with the mac. (That's my current form of "virtualization" ;-) I'll do this if ubuntu and HP work well together. Thoughts? That's where I've ended up for my xmonad development (well, still setting it up), since xmonad is crashing when I use a ghc that is built against MacPorts (both MP's own GHC and a locally built up to date haskell-platform) which I need for X11-xft :/
I am now set up on ubuntu 11.04. Code using Graphics.SOE.Gtk is running without a hitch. Thanks again.
-- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On Fri, Nov 25, 2011 at 6:41 PM, Philippe Sismondi
After exchanging posts with you I surfed the web a bit, and came to the conclusion that architecture is something of a problem for quite a few OS X users of ghc. Is that fair to say?
If you're not trying to link against MacPorts it works great, but MacPorts is the easiest way to install various free software packages. I haven't tried the 64-bit GHC on OS X in a while. Antoine
participants (3)
-
Antoine Latter
-
Brandon Allbery
-
Philippe Sismondi