On Mon, Sep 5, 2011 at 10:24 PM, Duncan Coutts
> On Mon, 2011-09-05 at 16:13 +0100, John Lato wrote:
>> > From: Duncan Coutts <duncan.coutts@...>
>> > I've yet to hear any about build results on OSX or Windows. If you have
>> > tried or do try on either of those platforms then please let us know. I
>> > think that is the only thing we are now waiting for, so please send in
>> > your build results.
>> I successfully built the core packages and gtkglext on OS X 10.6.
>> This is with ghc-7.2.1, x86-64, and macports-based gtk (all packages
>> built with -fhave-quartz-gtk).
> Great, thanks.
> Would you mind helping me clear up my confusion...
> Does macports provide a native build of Gtk+? I thought it only provided
> the X11 backend.
The gtk2 port provides both (only one per install of course). The
native build is available by selecting the +quartz variant. Many of
the additional packages won't work with the native backend because
they depend on X11, but there is a +quartz variant of gtkglext-1.2.0
>> Note that the gtkglext extension is currently unusable with the quartz
>> backend because a few functions aren't exported.
> I was under the impression that the gtkglext C lib only worked for Gtk's
> X11 backend on OSX, not the native quartz backend.
AFAICT gtkglext C lib works perfectly with the native backend.
>> I've attached a patch which adds the flag have-quartz-gtk to gtkglext
>> for this case. There's also a flag to disable some deprecated pango
>> functions which may not be available with newer gtkglext's.
> So you're saying that gtkglext builds against Gtk+ with it's native
> backend and actually works? (What gtkglext version is that? Even version
> 1.2 is now ancient.) And then with this patch we can bind it ok.
Yes, where "works" means I could successfully run the demo program
(cube). I tested this with gtkglext-1.2.0 +quartz variant and also
the latest source checked out from git://git.gnome.org/gtkglext. You
can use the gtkglext repo with macports gtk+, although I needed to
update my pkg-config path (the macports pkg-config doesn't look in
/usr/local/ by default).
The `use-deprecated` flag (the first patch I included) must be set to
false (default) to link to a recent gtkglext because they've dropped
some pango-based functions. I think this would be true on all
> I'm surprised, but in a good way. :-)
> So if this all works with macports Gtk+ and native Gtk+ backend, would
> you mind helping us update the wiki page accurately.
I'll update the wiki; I think I need to get an account though so it
may take a few days.
> I expect Conal Elliott will be pleased. He's been complaining about the
> lack of the GL extension in the native Gtk+ backend in the past.
I hope it's useful.
There's still the libiconv issue, but I don't think we can fix that.
I've taken to self-compiling ghc to use the macports libiconv, which
solves it completely. I've heard that homebrew is better in this
regard, but I haven't tried it yet.