After months of quiet yearning & frustration, I finally chewed into a big bullet and got Gtk2Hs installed on my Mac (OS 10.6.4 with GHC 6.12.3).
It was a long and harrowing affair. There were many confusing error messages. Ultimately, though, it was just a process of being patient with the various package managers and manually chasing down dependencies that are external to cabal. I had to use both Fink and MacPorts (and had to do lots of time-consuming
selfupdate runs on these).
Here are the packages I can remember having to install:
glib (from Fink)
gtk+2 (from Fink; NB
- freetype (??)
- fontconfig (??)
cairo (from MacPorts)
pango (from MacPorts)
After all that,
cabal install gtk just worked. I was able to run example programs from this Gtk2Hs tutorial and get the windows to pop up and work correctly.
Running Fink and MacPorts is like having bacon on your sausage; it's a little redundant and includes much cholesterol, but it's easy to do and feels good at the time. Why I did this, or felt I had to, is now lost to me as well.
Misc. Stumbling Blocks
It bears noting that
gtk+ are essentially synonyms, so don't go hunting for one when you've got the other. On the other hand, a "2" suffix there is essential:
gtk-2.0 have nothing to do with "
gtk" or "
gtk 1.x"; they're essentially different products.
Several times I thought I was set having installed, say, the
gtk+2-shlibs packages from Fink, only to receive a complaint that gtk+2.pc (the
pkg-config data file which other packages use to locate
gtk+2) was missing, which made me gnash my teeth. The fix was to also install
gtk+2-dev, which apparently should be called
I've had a number of minor 32- vs 64-bit problems with GHC. It seems that Haskell Platform installs a 32-bit
ghc. (Why would this be? GHC does run 64-bit on MacOS, doesn't it?). Sometimes package managers install fat versions of libraries, which is good, but when using both Fink and MacPorts, a library with 64-bit-only versions might shadow the other.
Somewhere in the darkness, I had a problem with
zlib being 64-bit and hence unusable, and I couldn't determine which library was using it in order to muck with it (it wasn't
glib, nor the Haskell
zlib bindings). This was fixed by un- and re-installing GHC via Haskell Platform, which entailed a minor version upgrade as well as perhaps clearing any strange customizations that I can't deny making to the 32-bitness of my GHC install.
(I'm surprised there's not a better system for managing such library flavors on OS X. Couldn't we keep separate system paths like
/usr/local/lib64 and such? Or would this be a greater nightmare in itself?)
I wish this were a more helpful document. If you try this soon, and hit a snag, let me know and I'll either remember how I resolved it, or try to add to what's here.