Hi, 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 message The full description and bug tracing so far I described here: http://groups.google.com/group/haskell-charts/msg/9c8e4420b517c4f7 (also here http://osdir.com/ml/glasgow-haskell-users@haskell.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.22/gtk+-bundle_2.22.1-... http://ftp.acc.umu.se/pub/gnome/binaries/win32/glade3/3.6/glade3-3.6.7-with-... 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. Greets Daniel 2011/5/5 Albert Y. C. Lai :

Just 5 weeks ago,

http://thread.gmane.org/gmane.comp.lang.haskell.cafe/86738/focus=87456

Did anyone see it?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Ryan, thanks for adopting party. Daniel 2011/5/5 Ryan Yates :

Daniel,

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 (http://www.haskell.org/pipermail/haskell-cafe/2011-February/088829.html).  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 traction there.

Ryan

On Thu, May 5, 2011 at 4:25 AM, Daniel Kahlenberg wrote:

...

Hi,

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 message The full description and bug tracing so far I described here: http://groups.google.com/group/haskell-charts/msg/9c8e4420b517c4f7 (also here http://osdir.com/ml/glasgow-haskell-users@haskell.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.22/gtk+-bundle_2.22.1-...

http://ftp.acc.umu.se/pub/gnome/binaries/win32/glade3/3.6/glade3-3.6.7-with-...

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.

Greets Daniel

2011/5/5 Albert Y. C. Lai :

...

Just 5 weeks ago,

http://thread.gmane.org/gmane.comp.lang.haskell.cafe/86738/focus=87456

Did anyone see it?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 05/05/2011 09:50 PM, Andrew Coppin wrote:

On 05/05/2011 01:32 AM, Albert Y. C. Lai wrote:

...

Just 5 weeks ago,

http://thread.gmane.org/gmane.comp.lang.haskell.cafe/86738/focus=87456

Did anyone see it?

Right. So the problem might be GTK+ v3?

Wrong. Apparently the bundle I downloaded contains GTK+ 2.20, which is fine. But the page above clarifies what the real problem is: HP 2011.2.0.1 doesn't work, apparently. (Doesn't say why.)