[Haskell-cafe] Can't build Gtk2hs on Windows
fryguybob at gmail.com
Thu May 5 15:17:01 CEST 2011
Nice summery. I think one of the difficult issues is my "patch" in
http://hackage.haskell.org/trac/gtk2hs/ticket/1203 is something worthy
of scare quotes. I'm not a Cabal developer and I have no clue what
the implications of that change are. For all I know things would
cease working on Linux with the patch applied. I think it is sane,
but to verify that would require me to know a lot more about Cabal's
workings then I have time to do. Cabal-dev addresses this nicely in
that it isolates the unknowns. The global workaround is bad because
it is even less isolated but has the benefit that you do not have to
patch the setups.
Another issue is that the gtk2hs Trac makes you login as guest. As
such, I can't add myself to the CC list and this makes it is hard to
tell how many people are running into this issue. Similarly the
gtk2hs website being down makes it look like gtk2hs is dead. I know
that it is in all likelihood down due to the server switch
The Trac issue is probably due to an updated version of Trac changing
how CC field is set.
All of these little (very understandable) things compound the issue
and frustrate people. It is a good sign that people are expecting
things to work and the issues in the way are small. There are just
too few people with the means to fix those small issues, but I'm glad
they do the work they do.
I'm also sending this to the gtk2hs list to see if it can get some
On Thu, May 5, 2011 at 4:25 AM, Daniel Kahlenberg
<d.kahlenberg at googlemail.com> wrote:
> I have no spaces in my GTK installation path (h:\gtk+ there is no
> other gtk+, zlib1.dll etc. in my search path). The "patch"
> http://hackage.haskell.org/trac/gtk2hs/ticket/1203 is easier handled
> when using the cab/cabal-dev combination as I described here:
> http://article.gmane.org/gmane.comp.lang.haskell.cafe/88022, although
> this is no long-term solution, I agree.
> (I don't agree to let users require to install more or less arbitrary
> packages globally as long as a separation of permissions is reasonable
> for complex systems. Don't get me wrong: I would respect the advice if
> I had other information but I'm even not convinced.)
> The problem persists anyhow - with all backend gtk versions I tried -
> that building certain packages depending on the bundled cairo package,
> fail with a "unknown symbol `_cairo_image_surface_get_data'" error
> The full description and bug tracing so far I described here:
> (also here http://firstname.lastname@example.org/2011-04/msg00007.html).
> All in all I even thought about replacing/augmenting the gtk+ calls in
> e. g. timeplot code by wx calls or something like that to have a
> chance to use these nice tools on windows too, to circumvent
> regression on parallel installs of legacy ghc versions, have no idea
> either ;) Maybe an API comparison table in the WIKI might help here.
> GTK versions I sampled (all three with ghc-7.0.3, the first one also
> with ghc-7.0.2), yielding overall the same results:
> http://ftp.acc.umu.se/pub/gnome/binaries/win32/gtk+/2.24/ with the
> bundled tools manually installed using the components.lst file from
> the -2.22.1-* bundle as a reference.
> The http://hackage.haskell.org/trac/gtk2hs/ticket/1209 issue is valid
> for older gtk versions (until around 2.16) only and can be bypassed by
> adding -f-have-gio, enabling the non-gio build at least.
> I agree that it is possibly a windows only specific issue. Might even
> relate to my mingw+msys setup, although I explicitly used the
> mingw-get tool to install the whole build environment. Possibly the
> patching hack (http://hackage.haskell.org/trac/gtk2hs/ticket/1203) is
> an issue factor itself if it lead to incompatible situation.
> 2011/5/5 Albert Y. C. Lai <trebla at vex.net>:
>> Just 5 weeks ago,
>> Did anyone see it?
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe