From: Christian M. <Chr...@df...> - 2010-05-27 14:28:22
|
Axel Simon schrieb: > Hi Ian, > > I can build this version on Mac OS X 10.5 and compile Gtk2Hs against it. > All concurrency demos work and the more complicated demos work that > trigger several levels of callbacks (to C and back to Haskell). 1. I could not install gtk2hs-0.11.0 under x86 Solaris. Linking /tmp/glib-0.11.025732/glib-0.11.0/dist/setup/setup ... Configuring glib-0.11.0... Preprocessing library glib-0.11.0... gtk2hsC2hs: Errors during expansion of binding hooks: ./System/Glib/GObject.chs:107: (column 22) [ERROR] >>> Unknown identifier! Cannot find a definition for `g_object_get_type' in the header file. cabal: Error: some packages failed to install: 2. under a x86 Mac with a GTK-2.14 framework I got: Linking /tmp/gtk-0.11.025922/gtk-0.11.0/dist/setup/setup ... Configuring gtk-0.11.0... setup: ./Graphics/UI/Gtk/General/IconTheme.chs: invalid argument cabal: Error: some packages failed to install: gtk-0.11.0 failed during the building phase. The exception was: ExitFailure 1 The packages cairo-0.11.0 gio-0.11.0 glib-0.11.0 pango-0.11.0 built fine. The GTK-2.14 framework is: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/gtk2-framework.dmg and originally came from http://r.research.att.com/ 3. Under linux we still have a problem with the new gtk2hs-0.11.0 version. http://trac.informatik.uni-bremen.de:8080/hets/ticket/794 > > Cheers, > Axel > > On May 23, 2010, at 20:42, Ian Lynagh wrote: > >> >> Hi all, >> >> We are pleased to announce the first release candidate for GHC 6.12.3: >> >> http://www.haskell.org/ghc/dist/6.12.3-rc1/ building and installing ghc-6.12.2.20100521, compiling and running our large hets binary (without gtk2hs) worked. Thanks Christian >> >> As well as the source tarball: >> ghc-6.12.2.20100521-src.tar.bz2 >> there are installers for Windows (i386) and OS X (i386), and binary >> distributions for x86_64/Linux and i386/Linux. >> >> >> Please test as much as possible; bugs are much cheaper if we find them >> before the release! >> >> >> Thanks >> Ian, on behalf of the GHC team >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Gla...@ha... >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
From: Christian M. <Chr...@df...> - 2010-05-27 15:15:19
|
Andy Stewart schrieb: > Hi Christian, > > Christian Maeder <Chr...@df...> writes: > >> Axel Simon schrieb: >>> Hi Ian, >>> >>> I can build this version on Mac OS X 10.5 and compile Gtk2Hs against it. >>> All concurrency demos work and the more complicated demos work that >>> trigger several levels of callbacks (to C and back to Haskell). >> 1. I could not install gtk2hs-0.11.0 under x86 Solaris. >> >> Linking /tmp/glib-0.11.025732/glib-0.11.0/dist/setup/setup ... >> Configuring glib-0.11.0... >> Preprocessing library glib-0.11.0... >> gtk2hsC2hs: Errors during expansion of binding hooks: >> >> ./System/Glib/GObject.chs:107: (column 22) [ERROR] >> >>> Unknown identifier! >> Cannot find a definition for `g_object_get_type' in the header file. >> >> cabal: Error: some packages failed to install: > Looks, it's a problem that glib can't found header file. > gtk2hs find header files base on pkg-config return. > > Can you run "pkg-config --cflags gobject-2.0"? Yes: -bash-3.00$ pkg-config --cflags gobject-2.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include >> 2. under a x86 Mac with a GTK-2.14 framework I got: >> >> Linking /tmp/gtk-0.11.025922/gtk-0.11.0/dist/setup/setup ... >> >> Configuring gtk-0.11.0... >> >> setup: ./Graphics/UI/Gtk/General/IconTheme.chs: invalid argument >> >> cabal: Error: some packages failed to install: >> >> gtk-0.11.0 failed during the building phase. The exception was: >> >> ExitFailure 1 > This is bug of Gtk2HsSetup.hs, has fix in darcs version. > > Cheers, > > -- Andy Thanks, (I'll wait for a hackage update) Christian |
From: Bulat Z. <bul...@gm...> - 2010-05-27 17:50:58
|
Hello Axel, Thursday, May 27, 2010, 8:42:08 PM, you wrote: > - you use -threaded to compile your program > - you only use postGUISync and postGUIAsync from threads different to > the Gtk2Hs thread > Is this true? If yes, I'll give you an elaboration on how threads are > supposed to work in Gtk+ (I think I finally understood this!) and what > I've changed in 0.11.0. i'm among (probably many) developers who interested to hear it. i believe that gtk2hs uses thread where it was initialized as main (this thread should be bound so it's either main thread or one created with runInBoundThread/forkOS) and the everything should either run in this thread directly, or in signal hadlers (that are executed in this thread) or via postGUISync/postGUIAsync. moreover postGUISync can't be used inside main GUI thread due to locking as you may remember, once i proposed to add wrapper that is equal to id in main GUI thread but equal to postGUISync in other threads. or even better, wrap all gtk2hs operations in this wrapper -- Best regards, Bulat mailto:Bul...@gm... |
From: Axel S. <Axe...@in...> - 2010-05-27 18:22:36
|
On 27.05.2010, at 19:50, Bulat Ziganshin wrote: > Hello Axel, > > Thursday, May 27, 2010, 8:42:08 PM, you wrote: > >> - you use -threaded to compile your program >> - you only use postGUISync and postGUIAsync from threads different to >> the Gtk2Hs thread > >> Is this true? If yes, I'll give you an elaboration on how threads are >> supposed to work in Gtk+ (I think I finally understood this!) and >> what >> I've changed in 0.11.0. > > i'm among (probably many) developers who interested to hear it. i > believe that gtk2hs uses thread where it was initialized as main (this > thread should be bound so it's either main thread or one created with > runInBoundThread/forkOS) and the everything should either run in this > thread directly, or in signal hadlers (that are executed in this > thread) or via postGUISync/postGUIAsync. moreover postGUISync can't be > used inside main GUI thread due to locking > > as you may remember, once i proposed to add wrapper that is equal to > id in main GUI thread but equal to postGUISync in other threads. or > even better, wrap all gtk2hs operations in this wrapper Yes, I should perhaps dig that up and implement it. I actually suspect that Christian ran either into this problem or that he doesn't compile with -threaded. Hopefully it's one of those two options and not another concurrency bug in Gtk2Hs. So the story with the threads is as follows: You can use just a single thread. This is done when you compile without -threaded. You need to do the 'addIdle 50 >> yield' trick. You can use the -threaded option to ghc or you use ghci. Now there exists one lock for the whole of Gtk+. This lock must be acquired before gtk_init is called. (This is what I fixed before the release: without it, it worked on Unix but not on Windows.) The lock remains acquired by the OS thread that calls Gtk+. In particular, it remains acquire as long as signals are pending and dispatched. The only time this look is released is when Gtk+ enters its main loop. It may then block on input or run an idle handler. During this time, it is possible for a different OS thread (or any odd Haskell thread that may or may not run in a different OS thread) to acquire the lock, modify some widget state and release the lock. However, most widget methods call also to the OS and accessing the Win32 API from more than one OS thread is not possible due to Win32 using some thread-local state. Thus, using this method for concurrent updates is not recommended. Enter postGUIAsync. This method will add an idle handler to the Gtk+ main loop (this is done by glib in a thread safe way) which executes an action from the idle handler. This idle handler will be called from the main loop and thus be in the Gtk+ OS thread. The action can therefore safely access all widget methods. Since the action is performed in the Gtk+ OS thread, no expensive computation should be done, merely the widgets should be updated. I hope this helps to clarify the thread situation in Gtk+. Cheers, Axel |
From: Christian M. <Chr...@df...> - 2010-05-28 09:27:40
|
Axel Simon schrieb: [...] >>>> 2. under a x86 Mac with a GTK-2.14 framework I got: >>>> >>>> Linking /tmp/gtk-0.11.025922/gtk-0.11.0/dist/setup/setup ... >>>> >>>> Configuring gtk-0.11.0... >>>> >>>> setup: ./Graphics/UI/Gtk/General/IconTheme.chs: invalid argument >>>> >>>> cabal: Error: some packages failed to install: >>>> >>>> gtk-0.11.0 failed during the building phase. The exception was: >>>> >>> >>> This bug occurs if you're running in anything else but UTF-8 locale. As >>> Andy said, this is fixed in darcs. >> >> Yes, it went through after changing my LANG environment variable, but I >> get a link error that I don't get without gtk and glade: >> >> ld: warning, duplicate dylib /opt/local/lib/libxml2.2.dylib >> ld: warning, duplicate dylib /opt/local/lib/libz.1.dylib >> ld: warning, duplicate dylib /opt/local/lib/libiconv.2.dylib >> ld: warning, duplicate dylib /opt/local/lib/libXrender.1.dylib >> ld: warning, duplicate dylib /opt/local/lib/libX11.6.dylib >> Undefined symbols: >> "_iconv_close", referenced from: >> _h_iconv_close in libHShaskeline-0.6.2.2.a(h_iconv.o) >> _hs_iconv_close in libHSbase-4.2.0.2.a(iconv.o) >> "_iconv_open", referenced from: >> _h_iconv_open in libHShaskeline-0.6.2.2.a(h_iconv.o) >> _hs_iconv_open in libHSbase-4.2.0.2.a(iconv.o) >> "_iconv", referenced from: >> _h_iconv in libHShaskeline-0.6.2.2.a(h_iconv.o) >> _hs_iconv in libHSbase-4.2.0.2.a(iconv.o) >> ld: symbol(s) not found >> collect2: ld returned 1 exit status >> > > This is a dreaded problem on Mac OS. Apple has it's iconv and > fink/MacPorts has it's iconv. And possibly your installer has some > iconv, too. Is it possible to take out /opt from your DYLD_LIBRARY_PATH > search path? /opt/local/lib was not in my DYLD_LIBRARY_PATH, but it was added to the library-dirs field when installing glib and cairo. Setting export PATH=/Library/Frameworks/GTK+.framework/Resources/bin:$PATH so that /Library/Frameworks/GTK+.framework/Resources/bin/pkg-config will be used and reinstalling all gtk2hs packages solved all linking problem (incl. warnings)! Thanks Christian [...] >>>> The GTK-2.14 framework is: >>>> http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/gtk2-framework.dmg >>>> >>>> >>>> and originally came from http://r.research.att.com/ [...] |
From: Axel S. <Axe...@in...> - 2010-05-28 10:18:19
|
On 28.05.2010, at 11:27, Christian Maeder wrote: >>> Yes, it went through after changing my LANG environment variable, >>> but I >>> get a link error that I don't get without gtk and glade: >>> >>> ld: warning, duplicate dylib /opt/local/lib/libxml2.2.dylib >>> ld: warning, duplicate dylib /opt/local/lib/libz.1.dylib >>> ld: warning, duplicate dylib /opt/local/lib/libiconv.2.dylib >>> ld: warning, duplicate dylib /opt/local/lib/libXrender.1.dylib >>> ld: warning, duplicate dylib /opt/local/lib/libX11.6.dylib >>> Undefined symbols: >>> "_iconv_close", referenced from: >>> _h_iconv_close in libHShaskeline-0.6.2.2.a(h_iconv.o) >>> _hs_iconv_close in libHSbase-4.2.0.2.a(iconv.o) >>> "_iconv_open", referenced from: >>> _h_iconv_open in libHShaskeline-0.6.2.2.a(h_iconv.o) >>> _hs_iconv_open in libHSbase-4.2.0.2.a(iconv.o) >>> "_iconv", referenced from: >>> _h_iconv in libHShaskeline-0.6.2.2.a(h_iconv.o) >>> _hs_iconv in libHSbase-4.2.0.2.a(iconv.o) >>> ld: symbol(s) not found >>> collect2: ld returned 1 exit status >>> >> >> This is a dreaded problem on Mac OS. Apple has it's iconv and >> fink/MacPorts has it's iconv. And possibly your installer has some >> iconv, too. Is it possible to take out /opt from your >> DYLD_LIBRARY_PATH >> search path? > > /opt/local/lib was not in my DYLD_LIBRARY_PATH, but it was added to > the > library-dirs field when installing glib and cairo. > > Setting > export PATH=/Library/Frameworks/GTK+.framework/Resources/bin:$PATH > so that /Library/Frameworks/GTK+.framework/Resources/bin/pkg-config > will > be used and reinstalling all gtk2hs packages solved all linking > problem > (incl. warnings)! Ok, that's always possible put it would be nicer if any packaged version works too. However, this is probably out of our control. We can't really do anything if the default search path contains an unwanted version of a library that we should find somewhere else. Cheers, Axel |
From: Bulat Z. <bul...@gm...> - 2010-05-28 15:19:50
|
Hello Christian, Friday, May 28, 2010, 6:43:39 PM, you wrote: > startMainLoop = forkIO_ $ do > unsafeInitGUIForThreadedRTS > mainGUI afaik, it's incorrect (look at my yesterday letter), you need to use forkOS -- Best regards, Bulat mailto:Bul...@gm... |
From: Christian M. <Chr...@df...> - 2010-05-28 15:45:43
|
Bulat Ziganshin schrieb: > Hello Christian, > > Friday, May 28, 2010, 6:43:39 PM, you wrote: > >> startMainLoop = forkIO_ $ do >> unsafeInitGUIForThreadedRTS >> mainGUI > > afaik, it's incorrect (look at my yesterday letter), you need to use forkOS It did not make any difference, replacing forkIO by forkOS. Christian |
From: Andy S. <laz...@gm...> - 2010-05-28 15:35:17
|
Bulat Ziganshin <bul...@gm...> writes: > Hello Christian, > > Friday, May 28, 2010, 6:43:39 PM, you wrote: > >> startMainLoop = forkIO_ $ do >> unsafeInitGUIForThreadedRTS >> mainGUI > > afaik, it's incorrect (look at my yesterday letter), you need to use forkOS Really? I think forkIO is enough, because you have enable "-threaded". Look my forkGuiIO_ define: ------------------------------> forkGuiIO_ start <------------------------------ module Hanatee.Toolkit.General.Gtk.Concurrent where import Control.Concurrent import Graphics.UI.Gtk -- | Fork GUI IO. forkGuiIO :: IO a -> (a -> IO ()) -> IO (MVar a, ThreadId, ThreadId) forkGuiIO calcAction guiAction = do -- Create signal MVar variable. signal <- newEmptyMVar -- Build new thread for long-time calculation. calcThreadId <- forkIO $ calcAction >>= putMVar signal -- fill signal when calculation finish -- Bulid new thread for listen signal. guiThreadId <- onGuiSignal signal guiAction -- post GUI action to Gtk+ thread when catch finish signal return (signal, calcThreadId, guiThreadId) -- | Simliar `forkGuiIO`, except return () forkGuiIO_ :: IO a -> (a -> IO ()) -> IO () forkGuiIO_ calcAction guiAction = forkGuiIO calcAction guiAction >> return () -- | Post GUI Action to Gtk+ thread when catch signal. onGuiSignal :: MVar a -> (a -> IO ()) -> IO ThreadId onGuiSignal signal guiAction = forkIO $ takeMVar signal >>= postGUIAsync . guiAction ------------------------------> forkGuiIO_ end <------------------------------ Cheers, -- Andy |
From: Bulat Z. <bul...@gm...> - 2010-06-04 09:14:30
|
Hello Axel, Friday, June 4, 2010, 12:50:25 PM, you wrote: > I'll probably also enhance the semantics of postGUISync and > postGUIAsync to allow positing from the GUI thread as well (in which > case these functions are a no-op). only postGUISync! postGUIAsync is already does what it should do - adds action to queue and returns control immediately -- Best regards, Bulat mailto:Bul...@gm... |
From: Axel S. <Axe...@in...> - 2010-06-04 10:57:27
|
Hi Bulat, On 04.06.2010, at 11:14, Bulat Ziganshin wrote: > Hello Axel, > > Friday, June 4, 2010, 12:50:25 PM, you wrote: > >> I'll probably also enhance the semantics of postGUISync and >> postGUIAsync to allow positing from the GUI thread as well (in which >> case these functions are a no-op). > > only postGUISync! postGUIAsync is already does what it should do - > adds action to queue and returns control immediately Ah, true indeed. Axel |
From: Andy S. <laz...@gm...> - 2010-05-27 14:55:25
|
Hi Christian, Christian Maeder <Chr...@df...> writes: > Axel Simon schrieb: >> Hi Ian, >> >> I can build this version on Mac OS X 10.5 and compile Gtk2Hs against it. >> All concurrency demos work and the more complicated demos work that >> trigger several levels of callbacks (to C and back to Haskell). > > 1. I could not install gtk2hs-0.11.0 under x86 Solaris. > > Linking /tmp/glib-0.11.025732/glib-0.11.0/dist/setup/setup ... > Configuring glib-0.11.0... > Preprocessing library glib-0.11.0... > gtk2hsC2hs: Errors during expansion of binding hooks: > > ./System/Glib/GObject.chs:107: (column 22) [ERROR] > >>> Unknown identifier! > Cannot find a definition for `g_object_get_type' in the header file. > > cabal: Error: some packages failed to install: Looks, it's a problem that glib can't found header file. gtk2hs find header files base on pkg-config return. Can you run "pkg-config --cflags gobject-2.0"? > > 2. under a x86 Mac with a GTK-2.14 framework I got: > > Linking /tmp/gtk-0.11.025922/gtk-0.11.0/dist/setup/setup ... > > Configuring gtk-0.11.0... > > setup: ./Graphics/UI/Gtk/General/IconTheme.chs: invalid argument > > cabal: Error: some packages failed to install: > > gtk-0.11.0 failed during the building phase. The exception was: > > ExitFailure 1 This is bug of Gtk2HsSetup.hs, has fix in darcs version. Cheers, -- Andy > > > The packages > cairo-0.11.0 > gio-0.11.0 > glib-0.11.0 > pango-0.11.0 > built fine. > > The GTK-2.14 framework is: > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/gtk2-framework.dmg > and originally came from http://r.research.att.com/ > > 3. Under linux we still have a problem with the new gtk2hs-0.11.0 version. > http://trac.informatik.uni-bremen.de:8080/hets/ticket/794 > >> >> Cheers, >> Axel >> >> On May 23, 2010, at 20:42, Ian Lynagh wrote: >> >>> >>> Hi all, >>> >>> We are pleased to announce the first release candidate for GHC 6.12.3: >>> >>> http://www.haskell.org/ghc/dist/6.12.3-rc1/ > > building and installing ghc-6.12.2.20100521, compiling and running our > large hets binary (without gtk2hs) worked. > > Thanks Christian > >>> >>> As well as the source tarball: >>> ghc-6.12.2.20100521-src.tar.bz2 >>> there are installers for Windows (i386) and OS X (i386), and binary >>> distributions for x86_64/Linux and i386/Linux. >>> >>> >>> Please test as much as possible; bugs are much cheaper if we find them >>> before the release! >>> >>> >>> Thanks >>> Ian, on behalf of the GHC team >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Gla...@ha... >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > ------------------------------------------------------------------------------ |
From: Andy S. <laz...@gm...> - 2010-05-27 15:20:18
|
Christian Maeder <Chr...@df...> writes: > Andy Stewart schrieb: >> Hi Christian, >> >> Christian Maeder <Chr...@df...> writes: >> >>> Axel Simon schrieb: >>>> Hi Ian, >>>> >>>> I can build this version on Mac OS X 10.5 and compile Gtk2Hs against it. >>>> All concurrency demos work and the more complicated demos work that >>>> trigger several levels of callbacks (to C and back to Haskell). >>> 1. I could not install gtk2hs-0.11.0 under x86 Solaris. >>> >>> Linking /tmp/glib-0.11.025732/glib-0.11.0/dist/setup/setup ... >>> Configuring glib-0.11.0... >>> Preprocessing library glib-0.11.0... >>> gtk2hsC2hs: Errors during expansion of binding hooks: >>> >>> ./System/Glib/GObject.chs:107: (column 22) [ERROR] >>> >>> Unknown identifier! >>> Cannot find a definition for `g_object_get_type' in the header file. >>> >>> cabal: Error: some packages failed to install: >> Looks, it's a problem that glib can't found header file. >> gtk2hs find header files base on pkg-config return. >> >> Can you run "pkg-config --cflags gobject-2.0"? > > Yes: > > -bash-3.00$ pkg-config --cflags gobject-2.0 > -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include Can you found `g_object_get_type` define in above header files? In my box, g_object_get_type define in file /usr/include/glib-2.0/gobject/gobject.h Cheers, -- Andy > >>> 2. under a x86 Mac with a GTK-2.14 framework I got: >>> >>> Linking /tmp/gtk-0.11.025922/gtk-0.11.0/dist/setup/setup ... >>> >>> Configuring gtk-0.11.0... >>> >>> setup: ./Graphics/UI/Gtk/General/IconTheme.chs: invalid argument >>> >>> cabal: Error: some packages failed to install: >>> >>> gtk-0.11.0 failed during the building phase. The exception was: >>> >>> ExitFailure 1 >> This is bug of Gtk2HsSetup.hs, has fix in darcs version. >> >> Cheers, >> >> -- Andy > > Thanks, (I'll wait for a hackage update) > Christian |
From: Christian M. <Chr...@df...> - 2010-05-27 15:53:32
Attachments:
gobject.h.gz
|
Andy Stewart schrieb: > Christian Maeder <Chr...@df...> writes: > [..] >>>> Configuring glib-0.11.0... >>>> Preprocessing library glib-0.11.0... >>>> gtk2hsC2hs: Errors during expansion of binding hooks: >>>> >>>> ./System/Glib/GObject.chs:107: (column 22) [ERROR] >>>> >>> Unknown identifier! >>>> Cannot find a definition for `g_object_get_type' in the header file. [...] >>> Can you run "pkg-config --cflags gobject-2.0"? >> Yes: >> >> -bash-3.00$ pkg-config --cflags gobject-2.0 >> -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include > Can you found `g_object_get_type` define in above header > files? > > In my box, g_object_get_type define in file > > /usr/include/glib-2.0/gobject/gobject.h In my file /usr/local/include/glib-2.0/gobject/gobject.h (gzipped and attached) g_object_get_type is missing. Christian > > Cheers, > > -- Andy |
From: Axel S. <Axe...@in...> - 2010-05-27 16:42:18
|
On 27.05.2010, at 16:28, Christian Maeder wrote: > Axel Simon schrieb: >> Hi Ian, >> >> I can build this version on Mac OS X 10.5 and compile Gtk2Hs >> against it. >> All concurrency demos work and the more complicated demos work that >> trigger several levels of callbacks (to C and back to Haskell). > > 1. I could not install gtk2hs-0.11.0 under x86 Solaris. > > Linking /tmp/glib-0.11.025732/glib-0.11.0/dist/setup/setup ... > Configuring glib-0.11.0... > Preprocessing library glib-0.11.0... > gtk2hsC2hs: Errors during expansion of binding hooks: > > ./System/Glib/GObject.chs:107: (column 22) [ERROR] >>>> Unknown identifier! > Cannot find a definition for `g_object_get_type' in the header file. > Yup, we didn't test on Solaris. However, this is a Gtk+ version problem. The above mentioned function does not exist in Gtk+ 2.14 because it would be equivalent to G_TYPE_OBJECT. I've fixed this in the darcs repository. > cabal: Error: some packages failed to install: > > 2. under a x86 Mac with a GTK-2.14 framework I got: > > Linking /tmp/gtk-0.11.025922/gtk-0.11.0/dist/setup/setup ... > > Configuring gtk-0.11.0... > > setup: ./Graphics/UI/Gtk/General/IconTheme.chs: invalid argument > > cabal: Error: some packages failed to install: > > gtk-0.11.0 failed during the building phase. The exception was: > This bug occurs if you're running in anything else but UTF-8 locale. As Andy said, this is fixed in darcs. > > The packages > cairo-0.11.0 > gio-0.11.0 > glib-0.11.0 > pango-0.11.0 > built fine. > > The GTK-2.14 framework is: > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/gtk2-framework.dmg > and originally came from http://r.research.att.com/ > For the next point, it would really help us, if you could check out the darcs repo and build again. That would then also entail ironing out the problems with Gtk+ 2.14. > 3. Under linux we still have a problem with the new gtk2hs-0.11.0 > version. > http://trac.informatik.uni-bremen.de:8080/hets/ticket/794 > This would be very interesting to resolve. I assume: - you use -threaded to compile your program - you only use postGUISync and postGUIAsync from threads different to the Gtk2Hs thread Is this true? If yes, I'll give you an elaboration on how threads are supposed to work in Gtk+ (I think I finally understood this!) and what I've changed in 0.11.0. Cheers, Axel >> >> Cheers, >> Axel >> >> On May 23, 2010, at 20:42, Ian Lynagh wrote: >> >>> >>> Hi all, >>> >>> We are pleased to announce the first release candidate for GHC >>> 6.12.3: >>> >>> http://www.haskell.org/ghc/dist/6.12.3-rc1/ > > building and installing ghc-6.12.2.20100521, compiling and running our > large hets binary (without gtk2hs) worked. > > Thanks Christian > >>> >>> As well as the source tarball: >>> ghc-6.12.2.20100521-src.tar.bz2 >>> there are installers for Windows (i386) and OS X (i386), and binary >>> distributions for x86_64/Linux and i386/Linux. >>> >>> >>> Please test as much as possible; bugs are much cheaper if we find >>> them >>> before the release! >>> >>> >>> Thanks >>> Ian, on behalf of the GHC team >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Gla...@ha... >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
From: Christian M. <Chr...@df...> - 2010-05-27 18:04:09
|
Axel Simon schrieb: > > On 27.05.2010, at 16:28, Christian Maeder wrote: > >> Axel Simon schrieb: >>> Hi Ian, >>> >>> I can build this version on Mac OS X 10.5 and compile Gtk2Hs against it. >>> All concurrency demos work and the more complicated demos work that >>> trigger several levels of callbacks (to C and back to Haskell). >> >> 1. I could not install gtk2hs-0.11.0 under x86 Solaris. >> >> Linking /tmp/glib-0.11.025732/glib-0.11.0/dist/setup/setup ... >> Configuring glib-0.11.0... >> Preprocessing library glib-0.11.0... >> gtk2hsC2hs: Errors during expansion of binding hooks: >> >> ./System/Glib/GObject.chs:107: (column 22) [ERROR] >>>>> Unknown identifier! >> Cannot find a definition for `g_object_get_type' in the header file. >> > > Yup, we didn't test on Solaris. "cabal install cairo" also fails: Linking /tmp/cairo-0.11.05437/cairo-0.11.0/dist/setup/setup ... Configuring cairo-0.11.0... Preprocessing library cairo-0.11.0... Building cairo-0.11.0... Graphics/Rendering/Cairo.hs:8:0: error: cairo-version.h: No such file or directory cabal: Error: some packages failed to install: > > However, this is a Gtk+ version problem. The above mentioned function > does not exist in Gtk+ 2.14 because it would be equivalent to > G_TYPE_OBJECT. I've fixed this in the darcs repository. > >> cabal: Error: some packages failed to install: >> >> 2. under a x86 Mac with a GTK-2.14 framework I got: >> >> Linking /tmp/gtk-0.11.025922/gtk-0.11.0/dist/setup/setup ... >> >> Configuring gtk-0.11.0... >> >> setup: ./Graphics/UI/Gtk/General/IconTheme.chs: invalid argument >> >> cabal: Error: some packages failed to install: >> >> gtk-0.11.0 failed during the building phase. The exception was: >> > > This bug occurs if you're running in anything else but UTF-8 locale. As > Andy said, this is fixed in darcs. Yes, it went through after changing my LANG environment variable, but I get a link error that I don't get without gtk and glade: ld: warning, duplicate dylib /opt/local/lib/libxml2.2.dylib ld: warning, duplicate dylib /opt/local/lib/libz.1.dylib ld: warning, duplicate dylib /opt/local/lib/libiconv.2.dylib ld: warning, duplicate dylib /opt/local/lib/libXrender.1.dylib ld: warning, duplicate dylib /opt/local/lib/libX11.6.dylib Undefined symbols: "_iconv_close", referenced from: _h_iconv_close in libHShaskeline-0.6.2.2.a(h_iconv.o) _hs_iconv_close in libHSbase-4.2.0.2.a(iconv.o) "_iconv_open", referenced from: _h_iconv_open in libHShaskeline-0.6.2.2.a(h_iconv.o) _hs_iconv_open in libHSbase-4.2.0.2.a(iconv.o) "_iconv", referenced from: _h_iconv in libHShaskeline-0.6.2.2.a(h_iconv.o) _hs_iconv in libHSbase-4.2.0.2.a(iconv.o) ld: symbol(s) not found collect2: ld returned 1 exit status >> >> The packages >> cairo-0.11.0 >> gio-0.11.0 >> glib-0.11.0 >> pango-0.11.0 >> built fine. >> >> The GTK-2.14 framework is: >> http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/gtk2-framework.dmg >> >> and originally came from http://r.research.att.com/ >> > > For the next point, it would really help us, if you could check out the > darcs repo and build again. That would then also entail ironing out the > problems with Gtk+ 2.14. > >> 3. Under linux we still have a problem with the new gtk2hs-0.11.0 >> version. >> http://trac.informatik.uni-bremen.de:8080/hets/ticket/794 >> > > This would be very interesting to resolve. > > I assume: > > - you use -threaded to compile your program yes, > - you only use postGUISync and postGUIAsync from threads different to > the Gtk2Hs thread I'm not sure about this (as I have not written the code). Are (plain) button actions executed in the same Gtk2Hs thread? (If so than postGUISync is called in the same thread.) If I omit postGUISync I get: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy->request)) >= 0)' failed. > Is this true? If yes, I'll give you an elaboration on how threads are > supposed to work in Gtk+ (I think I finally understood this!) and what > I've changed in 0.11.0. > > Cheers, > Axel Cheers Christian |
From: Axel S. <Axe...@in...> - 2010-05-27 18:33:47
|
Hi Christian, On 27.05.2010, at 20:03, Christian Maeder wrote: >> Yup, we didn't test on Solaris. > > "cabal install cairo" also fails: > > Linking /tmp/cairo-0.11.05437/cairo-0.11.0/dist/setup/setup ... > Configuring cairo-0.11.0... > Preprocessing library cairo-0.11.0... > Building cairo-0.11.0... > > Graphics/Rendering/Cairo.hs:8:0: > error: cairo-version.h: No such file or directory > cabal: Error: some packages failed to install: > Darn, so we need to find out since when Cairo defines its version number. What version of cairo do you have (pkg-config --modversion cairo)? >> >> However, this is a Gtk+ version problem. The above mentioned function >> does not exist in Gtk+ 2.14 because it would be equivalent to >> G_TYPE_OBJECT. I've fixed this in the darcs repository. >> >>> cabal: Error: some packages failed to install: >>> >>> 2. under a x86 Mac with a GTK-2.14 framework I got: >>> >>> Linking /tmp/gtk-0.11.025922/gtk-0.11.0/dist/setup/setup ... >>> >>> Configuring gtk-0.11.0... >>> >>> setup: ./Graphics/UI/Gtk/General/IconTheme.chs: invalid argument >>> >>> cabal: Error: some packages failed to install: >>> >>> gtk-0.11.0 failed during the building phase. The exception was: >>> >> >> This bug occurs if you're running in anything else but UTF-8 >> locale. As >> Andy said, this is fixed in darcs. > > Yes, it went through after changing my LANG environment variable, > but I > get a link error that I don't get without gtk and glade: > > ld: warning, duplicate dylib /opt/local/lib/libxml2.2.dylib > ld: warning, duplicate dylib /opt/local/lib/libz.1.dylib > ld: warning, duplicate dylib /opt/local/lib/libiconv.2.dylib > ld: warning, duplicate dylib /opt/local/lib/libXrender.1.dylib > ld: warning, duplicate dylib /opt/local/lib/libX11.6.dylib > Undefined symbols: > "_iconv_close", referenced from: > _h_iconv_close in libHShaskeline-0.6.2.2.a(h_iconv.o) > _hs_iconv_close in libHSbase-4.2.0.2.a(iconv.o) > "_iconv_open", referenced from: > _h_iconv_open in libHShaskeline-0.6.2.2.a(h_iconv.o) > _hs_iconv_open in libHSbase-4.2.0.2.a(iconv.o) > "_iconv", referenced from: > _h_iconv in libHShaskeline-0.6.2.2.a(h_iconv.o) > _hs_iconv in libHSbase-4.2.0.2.a(iconv.o) > ld: symbol(s) not found > collect2: ld returned 1 exit status > This is a dreaded problem on Mac OS. Apple has it's iconv and fink/ MacPorts has it's iconv. And possibly your installer has some iconv, too. Is it possible to take out /opt from your DYLD_LIBRARY_PATH search path? >>> >>> The packages >>> cairo-0.11.0 >>> gio-0.11.0 >>> glib-0.11.0 >>> pango-0.11.0 >>> built fine. >>> >>> The GTK-2.14 framework is: >>> http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/gtk2-framework.dmg >>> >>> and originally came from http://r.research.att.com/ >>> >> >> For the next point, it would really help us, if you could check out >> the >> darcs repo and build again. That would then also entail ironing out >> the >> problems with Gtk+ 2.14. >> >>> 3. Under linux we still have a problem with the new gtk2hs-0.11.0 >>> version. >>> http://trac.informatik.uni-bremen.de:8080/hets/ticket/794 >>> >> >> This would be very interesting to resolve. >> >> I assume: >> >> - you use -threaded to compile your program > > yes, > >> - you only use postGUISync and postGUIAsync from threads different to >> the Gtk2Hs thread > > I'm not sure about this (as I have not written the code). > Are (plain) button actions executed in the same Gtk2Hs thread? (If so > than postGUISync is called in the same thread.) > > If I omit postGUISync I get: > xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - > (dpy->request)) >= 0)' failed. > >> Is this true? If yes, I'll give you an elaboration on how threads are >> supposed to work in Gtk+ (I think I finally understood this!) and >> what >> I've changed in 0.11.0. Ok, the elaboration was in the other message. What do you mean exactly with 'button actions'? I assume you are talking about something like button `on` buttonClicked $ do modifyWidget w . So, yes, 'modifyWidget' will be executed in the same OS thread an writing "postGUIAsync $ modifyWidget w" will block as Bulat has mentioned. However, somewhere you must spawn a new thread which then calls Gtk2Hs somehow. Is it possible that you have some functions that do use postGUISync or postGUIAsync and which are used from both, the Gtk+ OS thread and some other thread? This would explain the blocking behaviour (posting from the Gtk+ OS thread) and the crashing behaviour (calling Gtk2Hs without postGUIAsync). We should probably add a function that posts or just executes the action, depending on whether it's running the the Gtk+ OS thread or not. This is what Bulat has suggested quite a while ago. Cheers, Axel |
From: Christian M. <Chr...@df...> - 2010-05-28 09:02:44
|
Axel Simon schrieb: > Hi Christian, > > On 27.05.2010, at 20:03, Christian Maeder wrote: >>> Yup, we didn't test on Solaris. >> "cabal install cairo" also fails: >> >> Linking /tmp/cairo-0.11.05437/cairo-0.11.0/dist/setup/setup ... >> Configuring cairo-0.11.0... >> Preprocessing library cairo-0.11.0... >> Building cairo-0.11.0... >> >> Graphics/Rendering/Cairo.hs:8:0: >> error: cairo-version.h: No such file or directory >> cabal: Error: some packages failed to install: >> > > Darn, so we need to find out since when Cairo defines its version > number. What version of cairo do you have (pkg-config --modversion > cairo)? -bash-3.00$ pkg-config --modversion cairo 1.4.14 -bash-3.00$ pkg-config --modversion pango 1.20.0 -bash-3.00$ pkg-config --modversion gtk 1.4.2 -bash-3.00$ pkg-config --modversion glib 1.2.10 Maybe this configuration is far too old? My last gtk2hs installation under x86 solaris was for ghc-6.8.3 with gtk2hs-0.9.13: gconf-0.9.13, glade-0.9.13, glib-0.9.13, gnomevfs-0.9.13, gtk-0.9.13, mozembed-0.9.13, soegtk-0.9.13, sourceview-0.9.13 without the packages cairo, pango and gio. "ghc-pkg describe gtk" shows: hs-libraries: HSgtk extra-libraries: gtk-x11-2.0 gdk-x11-2.0 atk-1.0 gdk_pixbuf-2.0 m mlib pangoxft-1.0 pangox-1.0 pango-1.0 gmodule-2.0 gthread-2.0 Christian |
From: Andy S. <laz...@gm...> - 2010-05-28 09:20:25
|
Christian Maeder <Chr...@df...> writes: > Axel Simon schrieb: >> Hi Christian, >> >> On 27.05.2010, at 20:03, Christian Maeder wrote: >>>> Yup, we didn't test on Solaris. >>> "cabal install cairo" also fails: >>> >>> Linking /tmp/cairo-0.11.05437/cairo-0.11.0/dist/setup/setup ... >>> Configuring cairo-0.11.0... >>> Preprocessing library cairo-0.11.0... >>> Building cairo-0.11.0... >>> >>> Graphics/Rendering/Cairo.hs:8:0: >>> error: cairo-version.h: No such file or directory >>> cabal: Error: some packages failed to install: >>> >> >> Darn, so we need to find out since when Cairo defines its version >> number. What version of cairo do you have (pkg-config --modversion >> cairo)? > > -bash-3.00$ pkg-config --modversion cairo > 1.4.14 > -bash-3.00$ pkg-config --modversion pango > 1.20.0 > -bash-3.00$ pkg-config --modversion gtk > 1.4.2 > -bash-3.00$ pkg-config --modversion glib > 1.2.10 > > Maybe this configuration is far too old? Yes, very old. Let gtk2hs support so old version is trouble, because almost all UNIX system have has departed gtk+-1.0. Can you upgrade your system? Cheers, -- Andy > > My last gtk2hs installation under x86 solaris was for ghc-6.8.3 with > gtk2hs-0.9.13: > > gconf-0.9.13, glade-0.9.13, glib-0.9.13, gnomevfs-0.9.13, gtk-0.9.13, > mozembed-0.9.13, soegtk-0.9.13, sourceview-0.9.13 > > without the packages cairo, pango and gio. "ghc-pkg describe gtk" shows: > > hs-libraries: HSgtk > extra-libraries: gtk-x11-2.0 gdk-x11-2.0 atk-1.0 gdk_pixbuf-2.0 m > mlib pangoxft-1.0 pangox-1.0 pango-1.0 gmodule-2.0 > gthread-2.0 > > > Christian > > ------------------------------------------------------------------------------ |
From: Axel S. <Axe...@in...> - 2010-05-28 10:16:23
|
On 28.05.2010, at 11:15, Andy Stewart wrote: > Christian Maeder <Chr...@df...> writes: > >> Axel Simon schrieb: >>> Hi Christian, >>> >>> On 27.05.2010, at 20:03, Christian Maeder wrote: >>>>> Yup, we didn't test on Solaris. >>>> "cabal install cairo" also fails: >>>> >>>> Linking /tmp/cairo-0.11.05437/cairo-0.11.0/dist/setup/setup ... >>>> Configuring cairo-0.11.0... >>>> Preprocessing library cairo-0.11.0... >>>> Building cairo-0.11.0... >>>> >>>> Graphics/Rendering/Cairo.hs:8:0: >>>> error: cairo-version.h: No such file or directory >>>> cabal: Error: some packages failed to install: >>>> >>> >>> Darn, so we need to find out since when Cairo defines its version >>> number. What version of cairo do you have (pkg-config --modversion >>> cairo)? >> >> -bash-3.00$ pkg-config --modversion cairo >> 1.4.14 >> -bash-3.00$ pkg-config --modversion pango >> 1.20.0 >> -bash-3.00$ pkg-config --modversion gtk >> 1.4.2 >> -bash-3.00$ pkg-config --modversion glib >> 1.2.10 >> >> Maybe this configuration is far too old? No, that's fine. We should support at least down to 2.8. You need to query pkg-config --modversion gtk+-2.0 pkg-config --modversion glib-2.0 Cheers, Axel |
From: Christian M. <Chr...@df...> - 2010-05-28 11:43:27
|
Axel Simon schrieb: > On 28.05.2010, at 11:15, Andy Stewart wrote: [...] >>>>> Graphics/Rendering/Cairo.hs:8:0: >>>>> error: cairo-version.h: No such file or directory >>>>> cabal: Error: some packages failed to install: >>>>> >>>> Darn, so we need to find out since when Cairo defines its version >>>> number. What version of cairo do you have (pkg-config --modversion >>>> cairo)? >>> -bash-3.00$ pkg-config --modversion cairo >>> 1.4.14 >>> -bash-3.00$ pkg-config --modversion pango >>> 1.20.0 >>> -bash-3.00$ pkg-config --modversion gtk >>> 1.4.2 >>> -bash-3.00$ pkg-config --modversion glib >>> 1.2.10 >>> >>> Maybe this configuration is far too old? > > No, that's fine. We should support at least down to 2.8. > > You need to query > > pkg-config --modversion gtk+-2.0 > pkg-config --modversion glib-2.0 -bash-3.00$ pkg-config --modversion glib-2.0 2.16.2 -bash-3.00$ pkg-config --modversion gio-2.0 2.16.2 -bash-3.00$ pkg-config --modversion gtk+-2.0 2.13.0 Christian |
From: Christian M. <Chr...@df...> - 2010-05-28 13:08:27
|
Our x86 solaris machine has now newer versions and the installation of gtk-0.11.0 succeeded. But our hets application (compiled with ghc-6.12.2.20100521) now crashes directly with "Segmentation Fault" and if called within "gdb" it shows: ... [New LWP 4] [LWP 4 exited] [New LWP 4] hets: Cannot initialize GUI. Cheers Christian I-bash-3.00$ pkg-config --modversion gtk+-2.0 2.16.5 -bash-3.00$ pkg-config --modversion glib-2.0 2.23.5 -bash-3.00$ pkg-config --modversion cairo 1.8.8 -bash-3.00$ pkg-config --modversion pango 1.24.5 Christian Maeder schrieb: > Axel Simon schrieb: >> On 28.05.2010, at 11:15, Andy Stewart wrote: > [...] >>>>>> Graphics/Rendering/Cairo.hs:8:0: >>>>>> error: cairo-version.h: No such file or directory >>>>>> cabal: Error: some packages failed to install: >>>>>> >>>>> Darn, so we need to find out since when Cairo defines its version >>>>> number. What version of cairo do you have (pkg-config --modversion >>>>> cairo)? >>>> -bash-3.00$ pkg-config --modversion cairo >>>> 1.4.14 >>>> -bash-3.00$ pkg-config --modversion pango >>>> 1.20.0 [...] > > -bash-3.00$ pkg-config --modversion glib-2.0 > 2.16.2 > > -bash-3.00$ pkg-config --modversion gio-2.0 > 2.16.2 > > -bash-3.00$ pkg-config --modversion gtk+-2.0 > 2.13.0 |
From: Andy S. <laz...@gm...> - 2010-05-28 13:50:22
|
Christian Maeder <Chr...@df...> writes: > Our x86 solaris machine has now newer versions and the installation of > gtk-0.11.0 succeeded. > > But our hets application (compiled with ghc-6.12.2.20100521) now crashes > directly with "Segmentation Fault" and if called within "gdb" it shows: Don't use ghc-6.12.2, we have found ghc-6.12.2 have runtime issue that will crash gtk2hs program. Look http://hackage.haskell.org/trac/ghc/ticket/4038 Use ghc-6.12.1 instead. Cheers, -- Andy > > ... > [New LWP 4] > > [LWP 4 exited] > [New LWP 4] > hets: Cannot initialize GUI. > > Cheers Christian > > I-bash-3.00$ pkg-config --modversion gtk+-2.0 > 2.16.5 > -bash-3.00$ pkg-config --modversion glib-2.0 > 2.23.5 > -bash-3.00$ pkg-config --modversion cairo > 1.8.8 > -bash-3.00$ pkg-config --modversion pango > 1.24.5 > > Christian Maeder schrieb: >> Axel Simon schrieb: >>> On 28.05.2010, at 11:15, Andy Stewart wrote: >> [...] >>>>>>> Graphics/Rendering/Cairo.hs:8:0: >>>>>>> error: cairo-version.h: No such file or directory >>>>>>> cabal: Error: some packages failed to install: >>>>>>> >>>>>> Darn, so we need to find out since when Cairo defines its version >>>>>> number. What version of cairo do you have (pkg-config --modversion >>>>>> cairo)? >>>>> -bash-3.00$ pkg-config --modversion cairo >>>>> 1.4.14 >>>>> -bash-3.00$ pkg-config --modversion pango >>>>> 1.20.0 > [...] >> >> -bash-3.00$ pkg-config --modversion glib-2.0 >> 2.16.2 >> >> -bash-3.00$ pkg-config --modversion gio-2.0 >> 2.16.2 >> >> -bash-3.00$ pkg-config --modversion gtk+-2.0 >> 2.13.0 > > > ------------------------------------------------------------------------------ |
From: Christian M. <Chr...@df...> - 2010-05-28 14:04:31
|
Andy Stewart schrieb: > Christian Maeder <Chr...@df...> writes: > >> Our x86 solaris machine has now newer versions and the installation of >> gtk-0.11.0 succeeded. >> >> But our hets application (compiled with ghc-6.12.2.20100521) now crashes >> directly with "Segmentation Fault" and if called within "gdb" it shows: > Don't use ghc-6.12.2, we have found ghc-6.12.2 have runtime issue that > will crash gtk2hs program. I know, that's a different issue. The same problem occurs with ghc-6.10.4 and gtk-0.11.0. initGUI (aka unsafeInitGUIForThreadedRTS) simply fails with "Cannot initialize GUI."! I suppose I should try out some gtk demo programs. Do I need to darcs get them? Why I also get a "Segmentation Fault" is a yet another issue. Cheers Christian > Look http://hackage.haskell.org/trac/ghc/ticket/4038 > > Use ghc-6.12.1 instead. > > Cheers, > > -- Andy > >> ... >> [New LWP 4] >> >> [LWP 4 exited] >> [New LWP 4] >> hets: Cannot initialize GUI. >> >> Cheers Christian >> >> I-bash-3.00$ pkg-config --modversion gtk+-2.0 >> 2.16.5 >> -bash-3.00$ pkg-config --modversion glib-2.0 >> 2.23.5 >> -bash-3.00$ pkg-config --modversion cairo >> 1.8.8 >> -bash-3.00$ pkg-config --modversion pango >> 1.24.5 >> >> Christian Maeder schrieb: >>> Axel Simon schrieb: >>>> On 28.05.2010, at 11:15, Andy Stewart wrote: >>> [...] >>>>>>>> Graphics/Rendering/Cairo.hs:8:0: >>>>>>>> error: cairo-version.h: No such file or directory >>>>>>>> cabal: Error: some packages failed to install: >>>>>>>> >>>>>>> Darn, so we need to find out since when Cairo defines its version >>>>>>> number. What version of cairo do you have (pkg-config --modversion >>>>>>> cairo)? >>>>>> -bash-3.00$ pkg-config --modversion cairo >>>>>> 1.4.14 >>>>>> -bash-3.00$ pkg-config --modversion pango >>>>>> 1.20.0 >> [...] >>> -bash-3.00$ pkg-config --modversion glib-2.0 >>> 2.16.2 >>> >>> -bash-3.00$ pkg-config --modversion gio-2.0 >>> 2.16.2 >>> >>> -bash-3.00$ pkg-config --modversion gtk+-2.0 >>> 2.13.0 >> >> ------------------------------------------------------------------------------ > > > ------------------------------------------------------------------------------ |
From: Andy S. <laz...@gm...> - 2010-05-28 14:17:54
|
Christian Maeder <Chr...@df...> writes: > Andy Stewart schrieb: >> Christian Maeder <Chr...@df...> writes: >> >>> Our x86 solaris machine has now newer versions and the installation of >>> gtk-0.11.0 succeeded. >>> >>> But our hets application (compiled with ghc-6.12.2.20100521) now crashes >>> directly with "Segmentation Fault" and if called within "gdb" it shows: >> Don't use ghc-6.12.2, we have found ghc-6.12.2 have runtime issue that >> will crash gtk2hs program. > > I know, that's a different issue. The same problem occurs with > ghc-6.10.4 and gtk-0.11.0. initGUI (aka unsafeInitGUIForThreadedRTS) > simply fails with "Cannot initialize GUI."! Oh, looks like is new issue. I think you need a minimum program make other people can recure this bug. > > I suppose I should try out some gtk demo programs. Do I need to darcs > get them? Yes, because we forgot add demo in gtk2hs-0.11.0 So you need get deom from darcs. Cheers, -- Andy > > Why I also get a "Segmentation Fault" is a yet another issue. > > Cheers Christian > >> Look http://hackage.haskell.org/trac/ghc/ticket/4038 >> >> Use ghc-6.12.1 instead. >> >> Cheers, >> >> -- Andy >> >>> ... >>> [New LWP 4] >>> >>> [LWP 4 exited] >>> [New LWP 4] >>> hets: Cannot initialize GUI. >>> >>> Cheers Christian >>> >>> I-bash-3.00$ pkg-config --modversion gtk+-2.0 >>> 2.16.5 >>> -bash-3.00$ pkg-config --modversion glib-2.0 >>> 2.23.5 >>> -bash-3.00$ pkg-config --modversion cairo >>> 1.8.8 >>> -bash-3.00$ pkg-config --modversion pango >>> 1.24.5 >>> >>> Christian Maeder schrieb: >>>> Axel Simon schrieb: >>>>> On 28.05.2010, at 11:15, Andy Stewart wrote: >>>> [...] >>>>>>>>> Graphics/Rendering/Cairo.hs:8:0: >>>>>>>>> error: cairo-version.h: No such file or directory >>>>>>>>> cabal: Error: some packages failed to install: >>>>>>>>> >>>>>>>> Darn, so we need to find out since when Cairo defines its version >>>>>>>> number. What version of cairo do you have (pkg-config --modversion >>>>>>>> cairo)? >>>>>>> -bash-3.00$ pkg-config --modversion cairo >>>>>>> 1.4.14 >>>>>>> -bash-3.00$ pkg-config --modversion pango >>>>>>> 1.20.0 >>> [...] >>>> -bash-3.00$ pkg-config --modversion glib-2.0 >>>> 2.16.2 >>>> >>>> -bash-3.00$ pkg-config --modversion gio-2.0 >>>> 2.16.2 >>>> >>>> -bash-3.00$ pkg-config --modversion gtk+-2.0 >>>> 2.13.0 >>> >>> ------------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------------ |