whoops, gtk2gs compile aborts, no c2hs installed. Reproducible: Always Steps to Reproduce:
Works fine for me without c2hs installed, because it seems to use a built-in version in this case. I guess c2hs should be added as a dependency anyway, but I cannot understand why it fails for you ... Duncan? ks
I must have misinterpreted the error message. I compiled it -gnome today and it finished.
gtk2hs does not need an extranal c2hs to build. It includes it's own patched version. There is a known issue that c2hs requires a load of memory (at least the way gtk2hs invokes it requires lots), like 400Mb of free RAM. So basically you need amachine with 512Mb RAM total. With USE="-gnome" , it may complete because compiling one of the gnome modules may take even more memory than the simple gtk module. With USE="gnome" it should pull in all the dependencies. What error message did you get exactly whith USE="gnome"? What version of gtk2hs were you emerging?
I only have 256M of physical ram, about 500M of swap. gtk2hs 0.9.6-r1. the error is not available yet.
Created attachment 44002 [details] compiler output from emerge to error /bin/sh: line 1: /bin/sed s/\(.*\)\.chs/\1.hs/: No such file or directory
Hi Duncan! I am trying to emerge gtk2hs on amd64 with 1GB. The complete bug reports in on SF - ghc-bugs #1071030, but maybe you can shed some light on it. In short: c2hs: internal error: update_fwd: unknown/strange object 12238336 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ /bin/sh: /bin/sed s/\(.*\)\.chs/\1.hs/: No such file or directory removing make[1]: *** [compile] Error 1 make[1]: Leaving directory `/var/tmp/portage/gtk2hs-0.9.6-r1/work/gtk2hs-0.9.6/gtk' make: *** [make-all] Error 1 I tried both options regarding 'gnome' flag - it's the same. Sincerely, Gour
If you want a smaller test case, you can pull out the bit from the build that is giving the error. Undoubtedly it will be the bit where c2hs processes the gtk header files and produces all the .hs files from all the .chs files. It'll be quite a long command since it looks across many directories and many files. See if you can reproduce it with just one input .chs file, namely 'general/Heiracharchy.chs'. That would tell us if the error happens during the scanning of the gtk header files or during expanding the hooks in the .chs file. If you need, I can probaly track down exactly what command from the build you need to run to run. I'm upgrading to an amd64 so in the next week or so I'll do a Gentoo reinstall with an amd64 profile and see if I can reproduce the problem.
BTW, on the memory issue see bug #69270 comment #32 for a patch that emits a warning if you try to build gtk2hs on a machine with not enough memory. (Sorry it's not a patch that dramatically reduces the memory usage of c2hs! That's longer term work)
Oops that'd be bug #69270 comment #36
Hi! >It'll be quite a long command since it looks across many directories and many >files. See if you can reproduce it with just one input .chs file, namely >'general/Heiracharchy.chs'. That would tell us if the error happens during the >scanning of the gtk header files or during expanding the hooks in the .chs >file. If you need, I can probaly track down exactly what command from the >build you need to run to run. The experiment yields some interesting results regarding the RTS options passed to the compiler: 1) with the following command ../c2hs/c2hs -C-D__signed=signed -C-D__GLASGOW_HASKELL__=602 +RTS -K10M -RTS ... I was able to compile the all the *.chs files up to the embedding/Socket.chs. Here are the other options: 2) the default command gaura-nitai gtk # ../c2hs/c2hs -C-D__signed=signed -C-D__GLASGOW_HASKELL__=602 +RTS -H180m -M350m -RTS -C-I/usr/include/glib-2.0 -C-I//usr/lib/glib-2.0/include-C-I/usr/include/gtk-2.0 -C-I//usr/lib/gtk-2.0/include -C-I/usr/X11R6/include -C-I/usr/include/pango-1.0 -C-I/usr/include/freetype2 -C-I/usr/include/atk-1.0 -iabstract:buttons:display:entry:general:layout:menuComboToolbar:misc:multiline:ornaments:scrolling:selectors:treeList:windows:gdk:glib:pango:../compat:embedding -o : gtk/gtk.h general/Hierarchy.chs c2hs: internal error: update_fwd: unknown/strange object 12015328 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ 3) without -H option: gaura-nitai gtk # ../c2hs/c2hs -C-D__signed=signed -C-D__GLASGOW_HASKELL__=602 +RTS -M350m -RTS -C-I/usr/include/glib-2.0 -C-I//usr/lib/glib-2.0/include -C-I/usr/include/gtk-2.0 -C-I//usr/lib/gtk-2.0/include -C-I/usr/X11R6/include -C-I/usr/include/pango-1.0 -C-I/usr/include/freetype2 -C-I/usr/include/atk-1.0 -iabstract:buttons:display:entry:general:layout:menuComboToolbar:misc:multiline:ornaments:scrolling:selectors:treeList:windows:gdk:glib:pango:../compat:embedding -o : gtk/gtk.h general/Hierarchy.chs c2hs: internal error: update_fwd: unknown/strange object -1787980528 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ 4) without H & M options: gaura-nitai gtk # ../c2hs/c2hs -C-D__signed=signed -C-D__GLASGOW_HASKELL__=602 -C-I/usr/include/glib-2.0 -C-I//usr/lib/glib-2.0/include -C-I/usr/include/gtk-2.0 -C-I//usr/lib/gtk-2.0/include -C-I/usr/X11R6/include -C-I/usr/include/pango-1.0 -C-I/usr/include/freetype2 -C-I/usr/include/atk-1.0 -iabstract:buttons:display:entry:general:layout:menuComboToolbar:misc:multiline:ornaments:scrolling:selectors:treeList:windows:gdk:glib:pango:../compat:embedding -o : gtk/gtk.h general/Hierarchy.chs Stack space overflow: current size 1048576 bytes. Use `+RTS -Ksize' to increase it. 5) with H, K & M options: gaura-nitai gtk # ../c2hs/c2hs -C-D__signed=signed -C-D__GLASGOW_HASKELL__=602 +RTS -H180m -K10M -M350m -RTS -C-I/usr/include/glib-2.0 -C-I//usr/lib/glib-2.0/include -C-I/usr/include/gtk-2.0 -C-I//usr/lib/gtk-2.0/include -C-I/usr/X11R6/include -C-I/usr/include/pango-1.0 -C-I/usr/include/freetype2 -C-I/usr/include/atk-1.0 -iabstract:buttons:display:entry:general:layout:menuComboToolbar:misc:multiline:ornaments:scrolling:selectors:treeList:windows:gdk:glib:pango:../compat:embedding -o : gtk/gtk.h general/Hierarchy.chs c2hs: internal error: update_fwd: unknown/strange object 12015328 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ 6) with H & K options (it works): gaura-nitai gtk # ../c2hs/c2hs -C-D__signed=signed -C-D__GLASGOW_HASKELL__=602 +RTS -H180m -K10M -RTS -C-I/usr/include/glib-2.0 -C-I//usr/lib/glib-2.0/include -C-I/usr/include/gtk-2.0 -C-I//usr/lib/gtk-2.0/include -C-I/usr/X11R6/include -C-I/usr/include/pango-1.0 -C-I/usr/include/freetype2 -C-I/usr/include/atk-1.0 -iabstract:buttons:display:entry:general:layout:menuComboToolbar:misc:multiline:ornaments:scrolling:selectors:treeList:windows:gdk:glib:pango:../compat:embedding -o : gtk/gtk.h general/Hierarchy.chs 7) with K & M options: gaura-nitai gtk # ../c2hs/c2hs -C-D__signed=signed -C-D__GLASGOW_HASKELL__=602 +RTS -K10M -M350m -RTS -C-I/usr/include/glib-2.0 -C-I//usr/lib/glib-2.0/include -C-I/usr/include/gtk-2.0 -C-I//usr/lib/gtk-2.0/include -C-I/usr/X11R6/include -C-I/usr/include/pango-1.0 -C-I/usr/include/freetype2 -C-I/usr/include/atk-1.0 -iabstract:buttons:display:entry:general:layout:menuComboToolbar:misc:multiline:ornaments:scrolling:selectors:treeList:windows:gdk:glib:pango:../compat:embedding -o : gtk/gtk.h general/Hierarchy.chs c2hs: internal error: update_fwd: unknown/strange object -1787980528 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ At the end I tried to emerge with H & K, but it fails with the old: c2hs: internal error: update_fwd: unknown/strange object error. Hope I'm of some help. >I'm upgrading to an amd64 so in the next week or so I'll do a Gentoo reinstall >with an amd64 profile and see if I can reproduce the problem. Ohh..that's great. I'm sure it will be a renaissance for a Haskell on Gentoo amd64. I'm sorry for being a noob for both ghc & Haskell, but hope that by the blessings of Haskell hackers I'd be able to master this (as it looks to me) wonderful language. Sincerely, Gour
Thanks for the detailed report. I'll forward this extra information to the ghc developers. > > I'm upgrading to an amd64 so in the next week or so I'll do a Gentoo > > reinstall with an amd64 profile and see if I can reproduce the problem. > Ohh..that's great. I'm sure it will be a renaissance for a Haskell on Gentoo amd64. Sadly at the moment I'm stuck with a machine that is only limping along and dearly in need of a BIOS upgrade (at the moment it only work in single channel memory mode and can only use half of a 512Mb stick without panicing!). How on earth does one flash a BIOS when one does not have windows or a floppy disk drive? A bootable dos cdrom perhaps?! I'll probably just have to borrow someones flppy drive.
Hi! >Sadly at the moment I'm stuck with a machine that is only limping along and dearly in need of a BIOS upgrade (at the moment it only work in single channel memory mode and can only use half of a 512Mb stick without panicing!). How on earth does one flash a BIOS when one does not have windows or a floppy disk drive? A bootable dos cdrom perhaps?! I'll probably just have to borrow someones flppy drive. That's what I find in forums: http://colt.projectgamma.com/bios/flashing.html (see thread: http://forums.gentoo.org/viewtopic.php?t=201514&highlight=bios+flash) Sincerely, Gour
Ta. I did actually get it to work in the end by burding a DrDos bootable cdrom with a floppy image containing the flashing utility and the rom image. I've been a bit busy in the past few days but I will eventually get round to doing an amd64 isntallation and testing out all the Haskell packages.
Simon M said that: > That crash message is from the compacting collector; you might be able > to get it to crash sooner by giving the +RTS -c option (turns on the > compacting collector always, not just when memory gets tight). It would be interesting to see if it always the compacting collector that is causing problems. To properly track this down one can build the debug version of the ghc rts which does extra consistency checks etc. It's not for the faint of heart however I fear. I'll talk to Simon about doing that when I get round to doing my amd64 installation.
I didn't realise this but it turns out that recent ghc's come with the debug version of the rts installed. Simon M says: > You get a debugging RTS installed by default with GHC these days, adding > the -debug option on the command line links the program with it. > The debug RTS has lots of ASSERTs and the debugging output modes (+RTS > -D<blah>). I've not found a reference yet where the -D<blah> modes are explained.
Hi! >I've been a bit busy in the past few days but I will eventually get round to >doing an amd64 isntallation and testing out all the Haskell packages. I wish happy New Year to all Gentoo Haskell team! Is there any progress with Haskell packages or do you wait for a 6.4 release? Sincerely, Gour
I hear that FFI callbacks are not working yet on amd64 for ghc see: http://www.haskell.org//pipermail/glasgow-haskell-users/2005-January/007611.html http://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_id=8032 So that'd mean that gtk2hs and wxHaskell will not work yet on amd64 with avaliable versions of ghc.
>I hear that FFI callbacks are not working yet on amd64 for ghc Funny, I emerged wxhaskell and compiled few samples, but didn't try to execute them :-( >So that'd mean that gtk2hs and wxHaskell will not work yet on amd64 with >avaliable versions of ghc. How hard is to implement the missing part? Sincerely, Gour
If you want to help out with this bit you'd need to know x86-64 assembly and either know or be willing to lookup info about the calling conventions of the x86-64 ABI. You could refer to the euivalent assembly code that does this bit for x86. This lives in: ghc/rts/Adjustor.c in the createAdjustor() function. You would also need to modify freeHaskellFunctionPtr() and possibly mallocBytesRWX() and initAdjustor(). You'd want to confer with Simon Marlow and maybe Thomas Pasch and Wolfgang Thaller.
>If you want to help out with this bit you'd need to know x86-64 assembly and >either know or be willing to lookup info about the calling conventions of the >x86-64 ABI. I'm afraid it has to wait for somebody more capable to do the needful :-( Hopefully there is some amd64 hacker around 'cause at the moment there is no amd64-gui-Haskell available :-() Sincerely, Gour
I think we can close this bug now. The problem of gtk2hs taking so much memory is mostly addressed by the ram check fin the ebuild. Upstream are also working on ways of reducing the memory required by the build. gtk2hs is marked -amd64 at the moment. The ghc bugs on amd64 will hopefully be addressed by the time of the 6.4.1 release. ghc 6.4 does now have full FFI support in cvs. 6.4.1 will contain that. Feel free to re-open this bug if there is anything I've missed.
