[Haskell-cafe] Re: Using Gtk2Hs version 0.9.12 on a PPC Mac

[Duncan Coutts]

On Sat, 2007-07-28 at 17:08 +0200, Thorkil Naur wrote:

> > So what I wonder is how we can make this work reliably. We use the flags
> > that pkg-config tells us to use, I'd rather not add platform-specific
> > hacks if we can get the pkg-config settings fixed. So I presume when you
> > run pkg-config --libs gtk+-2.0 it does not list -L/opt/local/lib, or if
> > it does it lists it after -L/usr/X11R6/lib. Is that the case?
> 
> For the GTK+ tutorial helloworld.c program:
> 
> > $ pkg-config --libs gtk+-2.0
> > -L/Users/thorkilnaur/tn/install/gtk+-2.10.14/lib -L/opt/local/lib 
> -L/usr/X11R6/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm 
> -lpangocairo-1.0 -lpango-1.0 -lcairo -lSM -lICE -lgobject-2.0 -lgmodule-2.0 
> -lglib-2.0 -lintl -liconv -lfreetype -lz -lfontconfig -lpng12 -lXrender -lX11
> > $ gcc -v -Wall -g helloworld.c -o helloworld `pkg-config --cflags gtk+-2.0` 
> `pkg-config --libs gtk+-2.0`
> > ...

> Scrutinizing the link arguments output by gcc, it appears that the -Ls and the 
> -ls specified on the gcc command have been separated and inserted between 
> other -Ls and -ls supplied by gcc. But the order of the -Ls produced by 
> pkg-config is retained and, as mentioned, this is the case that works without 
> change.

Ok.

> For the Gtk2Hs demo World.hs program, the matter is more complex, especially 
> since the link arguments generated by ghc presumably goes via ghc-pkg that I 
> have never studied in detail before. But let me venture a guess anyway.
> 
> First we look at the gtk package and its dependents:
> 
> > $ for p in gtk-0.9.12 glib-0.9.12 cairo-0.9.12; do echo $p: `ghc-pkg field 
> $p depends`; done
> > gtk-0.9.12: depends: base-2.0 mtl-1.0 glib-0.9.12 cairo-0.9.12
> > glib-0.9.12: depends: base-2.0
> > cairo-0.9.12: depends: base-2.0 mtl-1.0 glib-0.9.12
> > $
> 
> Further:
> 
> > $ for p in gtk-0.9.12 glib-0.9.12 cairo-0.9.12; do echo $p: `ghc-pkg field 
> $p library-dirs`; done
> > gtk-0.9.12: 
> library-dirs: /Users/thorkilnaur/tn/install/gtk+-2.10.14/lib /usr/X11R6/lib /Users/thorkilnaur/tn/install/gtk2hs-0.9.12/lib/gtk2hs
> > glib-0.9.12: 
> library-dirs: /opt/local/lib /Users/thorkilnaur/tn/install/gtk2hs-0.9.12/lib/gtk2hs
> > cairo-0.9.12: 
> library-dirs: /opt/local/lib /usr/X11R6/lib /Users/thorkilnaur/tn/install/gtk2hs-0.9.12/lib/gtk2hs
> > $
> 
> The actual link arguments constructed by ghc when compiling World.hs are:
> 
> > $ ghc -v --make World.hs -o helloworld
> > ...
> > Linking helloworld ...
> > *** Linker:
> > gcc -v -o helloworld World.o 
> -L/Users/thorkilnaur/tn/install/gtk+-2.10.14/lib -L/usr/X11R6/lib 
> -L/Users/thorkilnaur/tn/install/gtk2hs-0.9.12/lib/gtk2hs -L/opt/local/lib 
> -L/Users/thorkilnaur/tn/install/ghc-6.6-for-buildbot-20070221_1000/lib/ghc-6.6.20070220 
> -lHSgtk -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm 
> -lpangocairo-1.0 -lpango-1.0 -lcairo -lSM -lICE -lgmodule-2.0 -lfreetype -lz 
> -lfontconfig -lpng12 -lXrender -lX11 -lgthread-2.0 -lHScairo -lcairo -lSM 
> -lICE -lfreetype -lz -lfontconfig -lpng12 -lXrender -lX11 -lHSglib 
> -lgobject-2.0 -lglib-2.0 -lintl -liconv -lHSmtl -lHSbase -lHSbase_cbits 
> -lHSrts -lm -u _base_GHCziBase_Izh_static_info -u 
> > ...
> > $
> 
> The -Ls are:
> 
> > -L/Users/thorkilnaur/tn/install/gtk+-2.10.14/lib -L/usr/X11R6/lib 
> -L/Users/thorkilnaur/tn/install/gtk2hs-0.9.12/lib/gtk2hs -L/opt/local/lib 
> -L/Users/thorkilnaur/tn/install/ghc-6.6-for-buildbot-20070221_1000/lib/ghc-6.6.20070220
> 
> My guess is now that ghc constructs this list from the package library-dirs, 
> heaping new ones onto the growing list at the end. World.hs refers only 
> gtk-0.9.12 which for some reason doesn't refer /opt/local/lib. However, gtk 
> depends on glib and glib includes /opt/local/lib before /usr/X11R6/lib, but 
> because the latter already appears in the current list, the new one 
> (/opt/local/lib) is simply tucked onto the end. And so on, thereby explaining 
> why /opt/local/lib ends up appearing after /usr/X11R6/lib.

Yes, that's the culprit.

> I don't know what could be done about this, but certainly, the problem cannot 
> be said to be caused by GTK+. Really, the basic problem is this horrendously 
> primitive manner which is used on many of our systems of letting the order of 
> appearance in certain lists influence the outcome of important processes. 
> Plus, of course, the lack of possibility of warning users about this, for 
> example by reporting on ambiguous references in case symbols are defined in 
> multiple libraries.

Indeed, it's not Gtk+'s fault. It's the fact that we're splitting up the
flags pkg-config tells us about glib, and gtk+, assigning them to the
ghc packages glib and gtk and then reconstructing the link command line
- but in the wrong order.

I'll have to think about this.

Thanks for the detailed investigation Thorkil.

Duncan