From: Peter G. <pg...@gm...> - 2009-01-20 02:45:40
|
Hello everyone, A release candidate for Gtk2HS 0.10.0 is available at: http://code.haskell.org/~pgavin/gtk2hs-0.10.0/gtk2hs-0.10.0-rc-20090119.tar.gz Please test this on your platform. It should build on pretty much any platform that GHC 6.8 and Gtk+ 2.4 (or so) or later are supported on. You should also be able to build on Windows using MingW and MSYS. A windows binary installer will be provided soon. Pete |
From: Gour <go...@ma...> - 2009-01-20 07:25:15
|
>>>>> "Peter" == Peter Gavin <pg...@gm...> writes: Peter> Please test this on your platform. It should build on pretty Peter> much any platform that GHC 6.8 What about 6.10? Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- |
From: Peter G. <pg...@gm...> - 2009-01-20 07:19:12
|
On 1/20/2009 2:14 AM, Gour wrote: >>>>>> "Peter" == Peter Gavin<pg...@gm...> writes: >>>>>> > > Peter> Please test this on your platform. It should build on pretty > Peter> much any platform that GHC 6.8 > > What about 6.10? > Sorry, I should have said GHC 6.8 or greater. Pete |
From: Axel S. <Axe...@en...> - 2009-01-20 07:58:28
Attachments:
addTreeSortToDist.txt
|
Hi Pete, On Mon, 2009-01-19 at 21:45 -0500, Peter Gavin wrote: > Hello everyone, > > A release candidate for Gtk2HS 0.10.0 is available at: > > http://code.haskell.org/~pgavin/gtk2hs-0.10.0/gtk2hs-0.10.0-rc-20090119.tar.gz > > Please test this on your platform. It should build on pretty much any platform > that GHC 6.8 and Gtk+ 2.4 (or so) or later are supported on. You should also be > able to build on Windows using MingW and MSYS. A windows binary installer will > be provided soon. > Thanks a lot for putting this together. Two things: 1) I get: /users/absint/simona/local/bin/ghc +RTS -RTS -c tools/c2hs/base/errors/Errors.hs -o tools/c2hs/base/errors/Errors.o -O -itools/c2hs/base/admin:tools/c2hs/base/errors:tools/c2hs/base/general:tools/c2hs/base/state:tools/c2hs/base/syms:tools/c2hs/base/syntax:tools/c2hs/c:tools/c2hs/chs:tools/c2hs/gen:tools/c2hs/state:tools/c2hs/toplevel -package-conf package.conf.inplace -hide-all-packages -package base-3.0.1.0 -package haskell98-1.0.1.0 -package pretty-1.0.0.0 -package containers-0.1.0.1 -package array-0.1.0.0 tools/c2hs/base/errors/Errors.hs:44:0: Failed to load interface for `Position': Use -v to see a list of the files searched for. when generating the dependencies. I saw that you pushed a patch were you avoid a recursive invocation of 'make'. This might have caused it. The dependencies in c2hsLocal.deps are correct but I think they are not honoured by 'make' if it is not invoked recursively. Interestingly, the build continues and c2hs is built correctly on Linux. On Mac OS, the build stops with the error above. 2) I forgot to add ListSort.hs to the extra dist files, hence it is not included in the tarball and 'make installcheck' fails. Patch attached. Thanks a lot, Axel. |
From: Peter G. <pg...@gm...> - 2009-01-20 16:10:55
|
On 1/20/2009 2:58 AM, Axel Simon wrote: > Hi Pete, > > On Mon, 2009-01-19 at 21:45 -0500, Peter Gavin wrote: > >> Hello everyone, >> >> A release candidate for Gtk2HS 0.10.0 is available at: >> >> http://code.haskell.org/~pgavin/gtk2hs-0.10.0/gtk2hs-0.10.0-rc-20090119.tar.gz >> >> Please test this on your platform. It should build on pretty much any platform >> that GHC 6.8 and Gtk+ 2.4 (or so) or later are supported on. You should also be >> able to build on Windows using MingW and MSYS. A windows binary installer will >> be provided soon. >> >> > > Thanks a lot for putting this together. > > Two things: > > 1) > > I get: > /users/absint/simona/local/bin/ghc +RTS -RTS -c > tools/c2hs/base/errors/Errors.hs -o tools/c2hs/base/errors/Errors.o -O > -itools/c2hs/base/admin:tools/c2hs/base/errors:tools/c2hs/base/general:tools/c2hs/base/state:tools/c2hs/base/syms:tools/c2hs/base/syntax:tools/c2hs/c:tools/c2hs/chs:tools/c2hs/gen:tools/c2hs/state:tools/c2hs/toplevel -package-conf package.conf.inplace -hide-all-packages -package base-3.0.1.0 -package haskell98-1.0.1.0 -package pretty-1.0.0.0 -package containers-0.1.0.1 -package array-0.1.0.0 > > tools/c2hs/base/errors/Errors.hs:44:0: > Failed to load interface for `Position': > Use -v to see a list of the files searched for. > > when generating the dependencies. I saw that you pushed a patch were you > avoid a recursive invocation of 'make'. This might have caused it. The > dependencies in c2hsLocal.deps are correct but I think they are not > honoured by 'make' if it is not invoked recursively. > > Interestingly, the build continues and c2hs is built correctly on Linux. > On Mac OS, the build stops with the error above. > Hmm... I know why that error happens (and was expecting it to) but I'm surprised the build fails for you. What is happening is that when make starts, it tries to read all the included .dep files, which of course don't exist. So it tries to do what it can with the rules it has to build those files. The first thing it tries to build is the deps for c2hs. Once it does that, it continues building as far as it can (which is up until it gets to that Errors.hs file), after which it re-reads all the .dep files it can and starts completely over from scratch. It seems on your Mac installation make is quitting entirely, instead of just rereading the .dep file and building the c2hs sources in the correct order. What I wanted to figure out is if there was a way to have make reread a .dep file immediately after it's generated, instead of trying to build all the other .dep files first, then rereading them when that fails. So it sounds like your linux maching behaved the way I expected to, but your Mac didn't. I think I might have a solution for this, but I'm still thinking about it. In the mean time, running make twice should work fine and give correct results. > 2) > > I forgot to add ListSort.hs to the extra dist files, hence it is not > included in the tarball and 'make installcheck' fails. Patch attached. > > Ok, thanks. Pete |
From: Axel S. <Axe...@en...> - 2009-01-20 20:15:19
|
On Jan 20, 2009, at 17:10, Peter Gavin wrote: >> -itools/c2hs/base/admin:tools/c2hs/base/errors:tools/c2hs/base/ >> general:tools/c2hs/base/state:tools/c2hs/base/syms:tools/c2hs/base/ >> syntax:tools/c2hs/c:tools/c2hs/chs:tools/c2hs/gen:tools/c2hs/ >> state:tools/c2hs/toplevel -package-conf package.conf.inplace -hide- >> all-packages -package base-3.0.1.0 -package haskell98-1.0.1.0 - >> package pretty-1.0.0.0 -package containers-0.1.0.1 -package >> array-0.1.0.0 >> >> tools/c2hs/base/errors/Errors.hs:44:0: >> Failed to load interface for `Position': >> Use -v to see a list of the files searched for. >> >> when generating the dependencies. I saw that you pushed a patch >> were you >> avoid a recursive invocation of 'make'. This might have caused it. >> The >> dependencies in c2hsLocal.deps are correct but I think they are not >> honoured by 'make' if it is not invoked recursively. >> >> Interestingly, the build continues and c2hs is built correctly on >> Linux. >> On Mac OS, the build stops with the error above. >> > Hmm... I know why that error happens (and was expecting it to) > but I'm surprised the build fails for you. What is happening is > that when make starts, it tries to read all the included .dep > files, which of course don't exist. So it tries to do what it can > with the rules it has to build those files. The first thing it > tries to build is the deps for c2hs. Once it does that, it > continues building as far as it can (which is up until it gets to > that Errors.hs file), after which it re-reads all the .dep files it > can and starts completely over from scratch. It seems on your Mac > installation make is quitting entirely, instead of just rereading > the .dep file and building the c2hs sources in the correct order. > What I wanted to figure out is if there was a way to have make > reread a .dep file immediately after it's generated, instead of > trying to build all the other .dep files first, then rereading them > when that fails. So it sounds like your linux maching behaved the > way I expected to, but your Mac didn't. > > I think I might have a solution for this, but I'm still thinking > about it. In the mean time, running make twice should work fine > and give correct results. > This sounds rather brittle. The magic with -include blah.deps is that GNU make will try to make blah.deps, thereby triggering a recursive call to make which builds c2hsLocal and all .hs files and runs ghc to calculate dependencies. When the recursive make is done, the outer make will slurp in the dependencies in blah.deps as if they were always there. (The minus sign in front of include merely says it shouldn't raise a fatal error if the .deps file cannot be found. We could actually omit that I think.) I admit this is rather subtle. Indeed, this is the reason we're not yet using Cabal. So, under these consideration, your patch hunk ./mk/common.mk 201 -.chs.hs: [_$_] - $(strip if test -x $(C2HS); then :; else \ - $(MAKE) $(AM_MAKEFLAGS) $(C2HS); fi;) - $(strip if test -f $($(PKG)_PRECOMP); then :; else \ - $(MAKE) $(AM_MAKEFLAGS) $($(PKG)_PRECOMP); fi;) +.chs.hs: $(C2HS) that removed the recursive call to make breaks this hack since now the dependencies are part of the main make file. I think it breaks because make first re-invokes itself to build c2hsLocal, then it re- invokes itself to build c2hsLocal.deps. Sincere apologies for leaving you in the dark about this hackery. Another point I should raise is that the lines ifeq (,$(findstring clean,$(MAKECMDGOALS))) -include tools/c2hs/c2hsLocal.deps endif have a similar evilness: The space before the endif exploits a bug in automake that fails to recognize the ifeq .. endif clause which it would otherwise translate into something else. There might be more subtleties in our glorious makefile, but for now, I can't remember any more. GNU make -- it's a love-hate relationship, Axel. |
From: Peter G. <pg...@gm...> - 2009-01-20 22:47:41
|
On 1/20/2009 3:14 PM, Axel Simon wrote: > > On Jan 20, 2009, at 17:10, Peter Gavin wrote: > [..] > So, under these consideration, your patch > > hunk ./mk/common.mk 201 > -.chs.hs: [_$_] > - $(strip if test -x $(C2HS); then :; else \ > - $(MAKE) $(AM_MAKEFLAGS) $(C2HS); fi;) > - $(strip if test -f $($(PKG)_PRECOMP); then :; else \ > - $(MAKE) $(AM_MAKEFLAGS) $($(PKG)_PRECOMP); fi;) > +.chs.hs: $(C2HS) > > > that removed the recursive call to make breaks this hack since now the > dependencies are part of the main make file. I think it breaks because > make first re-invokes itself to build c2hsLocal, then it re-invokes > itself to build c2hsLocal.deps. Right, some of the subtle build problems we have and hear about on the lists are from this recursive make stuff happening, and the fact that the outer make is using what amounts to a different Makefile than the inner make. I'm pretty sure the makefile would work the way we want if make would re-read everything every time any of the included files are built. But it wants to try and build as much as possible in one pass, before re-reading the included files, so it causes an error while building c2hs. > > Sincere apologies for leaving you in the dark about this hackery. > Another point I should raise is that the lines > > ifeq (,$(findstring clean,$(MAKECMDGOALS))) > -include tools/c2hs/c2hsLocal.deps > endif > > have a similar evilness: The space before the endif exploits a bug in > automake that fails to recognize the ifeq .. endif clause which it > would otherwise translate into something else. Right, I knew about that :) > > There might be more subtleties in our glorious makefile, but for now, > I can't remember any more. The $(PKG) variable is pretty evil, if you ask me. Definitely not something I'd expect from Haskell programmers :) In any case, I found a solution that gets around these problems, but you might not like it. I added a rule to the makefile dep: $(EARLY_DEPS) where EARLY_DEPS contains tools/c2hs/c2hsLocal.deps and additionally any dep files generated with chsDepend. I also made it so make won't try to include the libHS*_a.deps files when building the dep target. Now, make dep will build these dependency files without any errors happening. After make dep is done, make can be run from start to finish without errors. I also added a line to the configure script making it run make dep at the end of config.status, so no build processes will need to be changed. I figure everything should still work ok for partially complete builds and rebuilds for developers etc. If you think this is ok, I'll go ahead and push it. Pete |
From: Peter G. <pg...@gm...> - 2009-01-20 23:40:54
|
On 1/20/2009 5:47 PM, Peter Gavin wrote: > I added a rule to the makefile > > dep: $(EARLY_DEPS) > > where EARLY_DEPS contains tools/c2hs/c2hsLocal.deps and additionally > any dep files generated with chsDepend. I also made it so make won't > try to include the libHS*_a.deps files when building the dep target. > Now, make dep will build these dependency files without any errors > happening. After make dep is done, make can be run from start to > finish without errors. I also added a line to the configure script > making it run make dep at the end of config.status, so no build > processes will need to be changed. I figure everything should still > work ok for partially complete builds and rebuilds for developers etc. > I found a way to do this so that make dep will be run from make instead of configure. Since automake's "all" target recursively runs make all-am, I made the all target depend on the dep target. So then make all will generate all the dependencies before recursing with make all-am. What do you think? Pete |
From: Axel S. <Axe...@en...> - 2009-01-21 07:39:56
|
On Tue, 2009-01-20 at 18:40 -0500, Peter Gavin wrote: > On 1/20/2009 5:47 PM, Peter Gavin wrote: > > I added a rule to the makefile > > > > dep: $(EARLY_DEPS) > > > > where EARLY_DEPS contains tools/c2hs/c2hsLocal.deps and additionally > > any dep files generated with chsDepend. I also made it so make won't > > try to include the libHS*_a.deps files when building the dep target. > > Now, make dep will build these dependency files without any errors > > happening. After make dep is done, make can be run from start to > > finish without errors. I also added a line to the configure script > > making it run make dep at the end of config.status, so no build > > processes will need to be changed. I figure everything should still > > work ok for partially complete builds and rebuilds for developers etc. > > > I found a way to do this so that make dep will be run from make instead > of configure. Since automake's "all" target recursively runs make > all-am, I made the all target depend on the dep target. So then make > all will generate all the dependencies before recursing with make > all-am. What do you think? Well, that pretty much amounts to what we had before: have make build dependencies (including c2hs and all .hs files) before building the rest. Except with the previous solution you invoke make recursively and use make's magic to include dependencies in original invocation whereas your solution first builds dependencies and then invokes make recursively to build everything. I think the previous solution is better, actually, since you can say 'make blah.hs' and it will rebuild the dependencies (if they are not there) whereas your solution will not rebuild the dependencies. The problems that crop up at the user site (when they need to run 'make distclean') relates to the choice not to rebuild dependencies once they've been built. Whenever the import relations between modules change the dependencies can be wrong and the build can fail. This happens a lot when people run 'darcs pull'. The choice not to rebuild the dependencies was a performance consideration. Since calculating dependencies is rather quick on modern computers, it should be acceptable to always rebuild dependencies and get rid of all dependency problems. For automatic dependency calculation, we probably need to say that a specific .deps file depends on all source files of that library. However, I don't know if that works out of the box. In a nutshell: I'd rather go back to the original way dependencies are built since your solution seems slightly worse. Cheers, Axel. |
From: Gour <go...@ma...> - 2009-01-21 07:55:35
|
>>>>> "Axel" == Axel Simon <Axe...@en...> writes: Axel> Sincere apologies for leaving you in the dark about this hackery. Axel> Another point I should raise is that the lines [...] Axel> GNU make -- it's a love-hate relationship, Axel. Huh, let's hope to get rid of autoconf-stuff and use Cabal asap so that gtk2hs can be more easily deployed. Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- |
From: Peter G. <pg...@gm...> - 2009-01-22 00:36:51
|
On 1/21/2009 2:39 AM, Axel Simon wrote: > Well, that pretty much amounts to what we had before: have make build > dependencies (including c2hs and all .hs files) before building the > rest. Except with the previous solution you invoke make recursively and > use make's magic to include dependencies in original invocation whereas > your solution first builds dependencies and then invokes make > recursively to build everything. > The difference is that before, the recursive make was attempted every time c2hs got run, while now, make knows what the real dependencies are and can proceed appropriately. The first step of building the dependencies is just to bootstrap. During the actual build, make still knows that the dep files are generated from the source files, and will update them as necessary (like they were before). If for instance, you modify a gtk source file (e.g. to add an import statement), and just run make libHSgtk.a to rebuild just that library, the dependencies should still be regenerated for the file that was modified. > The problems that crop up at the user site (when they need to run 'make > distclean') relates to the choice not to rebuild dependencies once > they've been built. Whenever the import relations between modules change > the dependencies can be wrong and the build can fail. This happens a lot > when people run 'darcs pull'. The choice not to rebuild the dependencies > was a performance consideration. Since calculating dependencies is > rather quick on modern computers, it should be acceptable to always > rebuild dependencies and get rid of all dependency problems. For > automatic dependency calculation, we probably need to say that a > specific .deps file depends on all source files of that library. > However, I don't know if that works out of the box. > The dependency files are still rebuilt whenever any source file changes, since there is a dependency from every .dep file to the sources that are read in producing it. Technically, you really don't want the object files or source files to depend on the .dep files; their not really dependencies, any more than the makefile itself is. If you want to rebuild a single file using e.g., make foo/bar.o, that will work, unless the tree is completely clean (in which case I think it will still work, you'll just get the error that we talked about earlier). In any case, make dep should always bring the tree up to where make foo/bar.o *will* work. And really, all that is absolutely needed to bootstrap the rest of the dependency generation is tools/c2hs/c2hsLocal.deps, and the files generated by chsDepend. As long as those are present, and (fairly close to) correct, the makefile should update them and any other out of date dependency files before proceeding with the rest of the build. Now, I think I neglected to mention what the purpose of all this was, otherwise I think we'd be in more of an agreement :) Initially I just wanted to clean up the makefile, but I then realized with a few small other changes, I would probably be able to get parallel builds working. And I did! My current build tree works with make -j4 on both my linux amd64 system, and my mac. (It doesn't work in windows, but I'm pretty sure it's a bug in the version of make I'm using on.) I'll go ahead and pushed the patches so you can test them; if you're still not convinced, I promise I'll change everything back to the way it was :) Pete |
From: Axel S. <Axe...@en...> - 2009-01-22 09:53:50
|
On Wed, 2009-01-21 at 19:36 -0500, Peter Gavin wrote: > On 1/21/2009 2:39 AM, Axel Simon wrote: > > Well, that pretty much amounts to what we had before: have make build > > dependencies (including c2hs and all .hs files) before building the > > rest. Except with the previous solution you invoke make recursively and > > use make's magic to include dependencies in original invocation whereas > > your solution first builds dependencies and then invokes make > > recursively to build everything. > > > The difference is that before, the recursive make was attempted every > time c2hs got run, while now, make knows what the real dependencies are > and can proceed appropriately. Really? But if c2hsLocal and the dependency files are up to date, then surely make wouldn't trigger the rule for building .deps files. I haven't check this though. I'll just take your word for it :-) > The first step of building the > dependencies is just to bootstrap. During the actual build, make still > knows that the dep files are generated from the source files, and will > update them as necessary (like they were before). Well, they weren't updated before. So if you've got that now then that is new. This is probably a good thing because this will help avoid the build problems when people use darcs. > If for instance, you modify a gtk source file (e.g. to add an import > statement), and just run make libHSgtk.a to rebuild just that library, > the dependencies should still be regenerated for the file that was modified. > > The problems that crop up at the user site (when they need to run 'make > > distclean') relates to the choice not to rebuild dependencies once > > they've been built. Whenever the import relations between modules change > > the dependencies can be wrong and the build can fail. This happens a lot > > when people run 'darcs pull'. The choice not to rebuild the dependencies > > was a performance consideration. Since calculating dependencies is > > rather quick on modern computers, it should be acceptable to always > > rebuild dependencies and get rid of all dependency problems. For > > automatic dependency calculation, we probably need to say that a > > specific .deps file depends on all source files of that library. > > However, I don't know if that works out of the box. > > > The dependency files are still rebuilt whenever any source file changes, > since there is a dependency from every .dep file to the sources that are > read in producing it. Technically, you really don't want the object > files or source files to depend on the .dep files; their not really > dependencies, any more than the makefile itself is. No but you want the .dep files to depend on the source files such that when the source files change, the dependencies are rebuilt. What I tried to say about 'make foo.o' working is that in a clean tree, the original Makefile would still build dependencies. If this works with your version too, fine! > If you want to > rebuild a single file using e.g., make foo/bar.o, that will work, unless > the tree is completely clean (in which case I think it will still work, > you'll just get the error that we talked about earlier). Which error? (Just to make sure I'm with you.) > In any case, > make dep should always bring the tree up to where make foo/bar.o *will* > work. And really, all that is absolutely needed to bootstrap the rest > of the dependency generation is tools/c2hs/c2hsLocal.deps, and the files > generated by chsDepend. As long as those are present, and (fairly close > to) correct, the makefile should update them and any other out of date > dependency files before proceeding with the rest of the build. > > Now, I think I neglected to mention what the purpose of all this was, > otherwise I think we'd be in more of an agreement :) Initially I just > wanted to clean up the makefile, but I then realized with a few small > other changes, I would probably be able to get parallel builds working. > And I did! My current build tree works with make -j4 on both my linux > amd64 system, and my mac. (It doesn't work in windows, but I'm pretty > sure it's a bug in the version of make I'm using on.) I'll go ahead and > pushed the patches so you can test them; if you're still not convinced, > I promise I'll change everything back to the way it was :) Well, if you gain something then it's worth it. I'm just weary of changing something that worked relatively well (with the deliberate performance choice of only building dependencies once) to something that is new, in particular, a few days before a release. I'll try to test it. At the moement, you seem to have renamed a file but without telling darcs: config.status: error: cannot find input file: tools/c2hs/toplevel/C2HSConfig.hs.in Cheers, Axel. |
From: Peter V. <bu...@gm...> - 2009-01-20 10:52:17
|
Super! Are there any detailed guidelines for building it on Windows, from scratch? I mean assuming that neither MSYS nor MinGW are installed and configured yet. Installing and configuring these correctly is very very tricky, and for GTK2HS, I never succeeded in getting it to build on Windows, and since I'm not a UNIX expert (otherwise I would not be using Windows in the first place ;-) I'm then stuck... On Tue, Jan 20, 2009 at 3:45 AM, Peter Gavin <pg...@gm...> wrote: > Hello everyone, > > A release candidate for Gtk2HS 0.10.0 is available at: > > > http://code.haskell.org/~pgavin/gtk2hs-0.10.0/gtk2hs-0.10.0-rc-20090119.tar.gz > > Please test this on your platform. It should build on pretty much any > platform > that GHC 6.8 and Gtk+ 2.4 (or so) or later are supported on. You should > also be > able to build on Windows using MingW and MSYS. A windows binary installer > will > be provided soon. > > Pete > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Gtk2hs-devel mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel > |
From: <ega...@ba...> - 2009-01-20 15:40:14
|
Peter Gavin <pg...@gm...> writes: > Hello everyone, > > A release candidate for Gtk2HS 0.10.0 is available at: > > http://code.haskell.org/~pgavin/gtk2hs-0.10.0/gtk2hs-0.10.0-rc-20090119.tar.gz > > Please test this on your platform. It should build on pretty much any platform > that GHC 6.8 and Gtk+ 2.4 (or so) or later are supported on. You should also be > able to build on Windows using MingW and MSYS. A windows binary installer will > be provided soon. This was apparently not fixed: Linking libHSsoegtk.a, for larger libs this can take quite some time... /usr/bin/ar: creating libHSsoegtk.a ranlib libHSsoegtk.a rm -rf gio/System/GIO/AsyncResult.o gio/System/GIO/AsyncResult_split/; mkdir -p gio/System/GIO/AsyncResult_split /home/egallego/my/lib/shell/ghc +RTS -RTS -split-objs -c gio/System/GIO/AsyncResult.hs -o gio/System/GIO/AsyncResult.o -O -XForeignFunctionInterface -fglasgow-exts -igio -package-conf package.conf.inplace -hide-all-packages -ignore-package gio -package base-4.0.0.0 -package bytestring-0.9.1.4 -package glib-0.10.0 -package-name gio-0.10.0 '-#include<gio/gio.h>' -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include gio/System/GIO/AsyncResult.chs:37:0: Failed to load interface for `System.GIO.Base': Use -v to see a list of the files searched for. make[1]: *** [gio/System/GIO/AsyncResult.o] Error 1 If I disable GIO it builds OK. My system is Debian Lenny with ghc 6.10.1 Please request more information if needed. Regards, Emilio |