Re: [Gtk2hs-users] cairo error: ghc.exe: unable to load package `cairo-0.12.0'
Hi again, I can't get my head around one question: On one side I can install gtk2hs with the workaround from http://hackage.haskell.org/trac/gtk2hs/ticket/1203 applied. When I run ghc-pkg list the packages are listed as installed and I can compile some demo apps - apart from the mentioned package load error in ghci - using them, BUT... ... when I try cabal install threadscope (as an example package depending on gtk2hs) it complains about cairo etc. not being installed and tries to re-install it on-the-fly failing due to whats described her: http://hackage.haskell.org/trac/gtk2hs/ticket/1203! As opposed to when I'm using the stepwise approach of cabal unpack first, then cabal configure etc. Also I found two slightly similar looking questions on the list, but again I don't feel skilled enough to make best use of them, maybe they help any other http://www.mail-archive.com/gtk2hs-devel@lists.sourceforge.net/msg00580.html http://www.mail-archive.com/gtk2hs-devel@lists.sourceforge.net/msg00598.html Cheers Daniel 2011/4/4 Axel Simon axel.si...@in.tum.de: Hi Daniel, On 04.04.2011, at 16:01, Daniel wrote: Hi list, I've built gtk2hs successfully for ghc-7.0.2, but if I try to load the example Drawing.hs from the cairo packages demo folder I get: *Main :load Drawing.hs [1 of 1] Compiling Main ( Drawing.hs, interpreted ) Ok, modules loaded: Main. *Main main Loading package transformers-0.2.2.0 ... linking ... done. Loading package mtl-2.0.1.0 ... linking ... done. Loading package array-0.3.0.2 ... linking ... done. Loading package containers-0.4.0.0 ... linking ... done. Loading package process-1.0.1.5 ... linking ... done. Loading package time-1.2.0.3 ... linking ... done. Loading package random-1.0.0.3 ... linking ... done. Loading package haskell98-1.1.0.1 ... linking ... done. Loading package cairo-0.12.0 ... linking ... interactive: C:/users/daniel/appd ata/roaming/cabal\cairo-0.12.0\ghc-7.0.2\HScairo-0.12.0.o: unknown symbol `_cair o_image_surface_get_data' ghc.exe: unable to load package `cairo-0.12.0' Have tried many things so far: * Starting with re-inited package database * Doing a $ nm /h/Gtk+/bin/libcairo-2.dll | grep -i cairo_image_surface_get_data yielding 68de04d8 T _cairo_image_surface_get_data * Temporarily renaming libcairo-2.dll (the only one found on my setup, even not-in-PATH ones are non-existent) yielding as expected dll not found error * as you can see there is no literal space in the gtk+ installation path (h:\Gtk+), only in the users haskell package installation path, but that's fairly standard with Windows I guess * Compilable with ghc --make ... though, but that's sadly not sufficient as Chart package isn't installable due to this issue If ghc --make works but interactively the object cannot be found, then it might be a ghc problem rather than ours, especially since the symbol exists in the DLL. Can somebody from the ghc group shed some light on the issue? Cheers, Axel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Rebuilding ghc changes interface hashes?
Dear ghc developers, I am currently rebuilding ghc-7.0.2 to upload some packaging changes. Unfortunately, this had the effect of changing the package id of base, which would require rebuilding every Haskell library. In the times of ghc-6.12, rebuilding the compiler left the hashes intact. Is there anything new in ghc-7 that interferes here? Also, the initial upload was built using ghc-6.12.1, while the upload now is build with ghc-7.0.2. Given that it is a two-stage compiler, I assume that the output should be identical, but it seems not to be the case. Any idea what could be causing this? Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-DDEBUG and testsuite
Hello all, If I run 'make fast' in the testsuite, with a stage2 compiler that has been built with -DDEBUG, should I be getting extra failures? Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Rebuilding ghc changes interface hashes?
On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote: Also, the initial upload was built using ghc-6.12.1, while the upload now is build with ghc-7.0.2. Given that it is a two-stage compiler, I assume that the output should be identical, but it seems not to be the case. Changing the bootstrapping compiler changes the ABIs. The same can happen if you interrupt and restart the build. http://hackage.haskell.org/trac/ghc/ticket/4012 Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Rebuilding ghc changes interface hashes?
Hi, Am Dienstag, den 05.04.2011, 18:51 +0200 schrieb Matthias Kilian: On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote: Also, the initial upload was built using ghc-6.12.1, while the upload now is build with ghc-7.0.2. Given that it is a two-stage compiler, I assume that the output should be identical, but it seems not to be the case. Changing the bootstrapping compiler changes the ABIs. The same can happen if you interrupt and restart the build. http://hackage.haskell.org/trac/ghc/ticket/4012 thanks for the pointer. I wish I had known earlier (no offence!) and made an extra round of ghc uploads before uploading several dozend of libraries, which need to be rebuild now. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -DDEBUG and testsuite
On 05/04/11 17:50, Edward Z. Yang wrote: Hello all, If I run 'make fast' in the testsuite, with a stage2 compiler that has been built with -DDEBUG, should I be getting extra failures? You shouldn't, but since we don't test that very often it's possible that some bugs have crept in. What failures are you seeing? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Rebuilding ghc changes interface hashes?
On 05/04/11 17:51, Matthias Kilian wrote: On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote: Also, the initial upload was built using ghc-6.12.1, while the upload now is build with ghc-7.0.2. Given that it is a two-stage compiler, I assume that the output should be identical, but it seems not to be the case. Changing the bootstrapping compiler changes the ABIs. The same can happen if you interrupt and restart the build. In general changes can creep in randomly, there's no direct link between changing the bootstrap compiler and getting different compilation results (as far as I know), but there are some small elements of randomness. I did manage to squash most causes of this, but a couple remain, see http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/RecompilationAvoidance#Interfacestability there may be others that I don't know about. I would really like to fix this, I'll think about whether we can make a deterministic sort-order for bindings in Core, that would fix the CSE issue. Cheers, Simon http://hackage.haskell.org/trac/ghc/ticket/4012 Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Rebuilding ghc changes interface hashes?
On Tue, Apr 05, 2011 at 08:51:52PM +0100, Simon Marlow wrote: On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote: Also, the initial upload was built using ghc-6.12.1, while the upload now is build with ghc-7.0.2. Given that it is a two-stage compiler, I assume that the output should be identical, but it seems not to be the case. Changing the bootstrapping compiler changes the ABIs. The same can happen if you interrupt and restart the build. In general changes can creep in randomly, there's no direct link between changing the bootstrap compiler and getting different compilation results (as far as I know), but there are some small elements of randomness. Oh, I confused those two problems again :-( But memories come back, and IIRC the problem with the bootstrapping compiler is caused by the Booter version (as printed by ghc --info) passed up to the stage2 compiler. Wasn't the plan (about a year ago) to remove this? If time permits, I'll send a patch in a few days, but I first have to follow the switch to git, and I also want to update our (OpenBSDs) ports to ghc-7.0.3 and hp-2011.2. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
