Re: GHC7 (on OSX.5)
On 3/21/11 4:16 AM, Christian Maeder wrote: Am 20.03.2011 20:01, schrieb wren ng thornton: So I'm having a go of installing ghc-7.0.2 and haskell-platform-2011.2.0.0 on OSX 10.5. Since 10.5 is no longer supported I've had to compile from source. The good news is, so far as I can tell, everything works right out of the box.[1] [...] [1] OSX 10.5.8 arch x86_64 (though it calls itself i386) Does your ghc-7.0.2 create 32 or 64 bit Code? What does ghc --info say? Xcode 3.1.2 (not that it matters) gcc 4.0.1 (i686-apple-darwin9-gcc-4.0.1 Apple Inc. build 5490) ghc 6.12.1 / hp 2010.1.0.0 As far as I know there was no 64bit ghc-6.12.x for MacOS. Is it possible to create a 64bit ghc starting with a 32Bit ghc? I don't think so and always used ghc-6.10.4 from macports to create 64bit binary-dists that have the suffix -x86_64-apple-darwin.tar.bz2 rather than -i386-apple-darwin.tar.bz2 for 32bit compilers. There was never a 64 bit 6.12.3 for OS X. I tried for a while to patch 6.12.3 to make a MacPorts release, but it became clear that there were many problems, and that it would be better to contribute fixes to ghc to support O X 64 bit. 7.0.2 is the first release that works (mostly) on OS X 64 bit. It still fails significantly more regression tests than on 64 bit linux (around 80 tests instead of around 10). On the other hand we won't get the remaining bugs out without more people trying it out. I've started to work on updating the ghc portfile to 7.0.2. There will be many fewer patches, but there are still some questions about what to do (should support for forcing a 32 bit build on a 64 bit platform be retained) and quite a bit of testing is needed. However, I need to upgrade my own development environment to 7.0.2, so I have some incentive to get the work done. In the MacPorts version I may include my runtime linker debug patch, which won't be available generally until 7.2.1. If more linker problems are suspected, this would give a complete view of what the linker was doing. Best, Greg -- Gregory Wright Antiope Associates LLC 18 Clay Street Fair Haven, New Jersey 07733 USA +1 732 924-4549 [office] +1 732 345-8378 [fax] gwri...@antiope.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Glasgow-haskell-users] os x 64-bit?
Hi John, I'll take a look at trac #2965. You should be able to build the 7.0.1-rc2 tarball simply by unpacking it and following the instructions in the README. (In short, configure, make then make install ought to work.) If it doesn't build properly out of the box, I'd be interested in hearing about it. AFAIK, only 6.10.4 has been tested as bootstrap compiler for 7.0.1-rc2, although I expect 6.12.3 should work too. There is always the possibility of some hiccup, however. Best Wishes, Greg On 11/11/10 6:17 AM, John Lato wrote: Hi Greg, Thanks very much for all your work on this, and Barney Stratford too. This is great news. I'm doing a lot of numerical work with Doubles at the moment, so progress is quite welcome! I can try building 7.0.1-RC using a 32-bit 6.12.3, although probably not until the weekend. I'll let you know how it goes. If there are any special build instructions for this, maybe you could update trac #2965 with details? Cheers, John From: Gregory Wright gwri...@antiope.com mailto:gwri...@antiope.com Hi, I built ghc 7.0.1-rc2 yesterday 64-bit on Snow Leopard. Much of the work in getting ghc to build 64-bit was done by Barney Stratford; the MacPorts ghc 6.10.4 has built successfully in 64 bit mode for a number of months. Until just a few weeks ago 6.12.x and HEAD wouldn't build 64-bit because of changes in ghci. These changes were in part to remove the limitation that modules loaded by ghci had to be located below the 2 GB address boundary. Unfortunately, they revealed code paths in ghc's Mach-O linker that were never tested. (See bug #4318. Other bugs may be partial duplicates; the tickets probably need to be examined to check which ones are distinct.) The good news is that the linker patches were done just in time for 7.0.1. You should be all set to try the release candidates on Snow Leopard 64-bit. I built my 7.0.1-rc2 using a 64 bit 6.10.4. My original 64-bit 6.10.4 was bootstrapped using a 32-bit 6.10.4 compiled on Leopard. Reports of trouble building the 7.0.1 release candidates using a 32-bit bootstrap compiler would be especially useful. Best Wishes, Greg On 11/9/10 12:48 PM, Brian Bloniarz wrote: On 11/09/2010 02:36 AM, John Lato wrote: I was wondering if there is a status report anywhere of progress towards making ghc compile 64-bit on Snow Leopard. There are a few trac tickets that seem related: I think http://hackage.haskell.org/trac/ghc/ticket/3472 is related if you haven't seen it. I'm not working on this, though I am interested in helping enable cross-compilation of GHC in general. I have been working on one facet though: hsc2hs. hsc2hs is one of barriers to cross-compilation because it requires compiling and running a .c file on the target machine (because it needs target-specific information like the layout of structures; GHC's mkDerivedConstants also has the same problem). I have a proof-of-concept patch which can do hsc2hs codegeneration without running anything. This uses the same approach that autoconf uses for cross-compilation. I'll try to post it within the next few days -- if anybody finds this approach interesting please let me know. Thanks, -Brian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: os x 64-bit?
Hi, I built ghc 7.0.1-rc2 yesterday 64-bit on Snow Leopard. Much of the work in getting ghc to build 64-bit was done by Barney Stratford; the MacPorts ghc 6.10.4 has built successfully in 64 bit mode for a number of months. Until just a few weeks ago 6.12.x and HEAD wouldn't build 64-bit because of changes in ghci. These changes were in part to remove the limitation that modules loaded by ghci had to be located below the 2 GB address boundary. Unfortunately, they revealed code paths in ghc's Mach-O linker that were never tested. (See bug #4318. Other bugs may be partial duplicates; the tickets probably need to be examined to check which ones are distinct.) The good news is that the linker patches were done just in time for 7.0.1. You should be all set to try the release candidates on Snow Leopard 64-bit. I built my 7.0.1-rc2 using a 64 bit 6.10.4. My original 64-bit 6.10.4 was bootstrapped using a 32-bit 6.10.4 compiled on Leopard. Reports of trouble building the 7.0.1 release candidates using a 32-bit bootstrap compiler would be especially useful. Best Wishes, Greg On 11/9/10 12:48 PM, Brian Bloniarz wrote: On 11/09/2010 02:36 AM, John Lato wrote: I was wondering if there is a status report anywhere of progress towards making ghc compile 64-bit on Snow Leopard. There are a few trac tickets that seem related: I think http://hackage.haskell.org/trac/ghc/ticket/3472 is related if you haven't seen it. I'm not working on this, though I am interested in helping enable cross-compilation of GHC in general. I have been working on one facet though: hsc2hs. hsc2hs is one of barriers to cross-compilation because it requires compiling and running a .c file on the target machine (because it needs target-specific information like the layout of structures; GHC's mkDerivedConstants also has the same problem). I have a proof-of-concept patch which can do hsc2hs codegeneration without running anything. This uses the same approach that autoconf uses for cross-compilation. I'll try to post it within the next few days -- if anybody finds this approach interesting please let me know. Thanks, -Brian ___ 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: os x 64-bit?
On 11/10/10 10:44 AM, Antoine Latter wrote: On Wed, Nov 10, 2010 at 9:04 AM, Gregory Wrightgwri...@antiope.com wrote: Hi, I built ghc 7.0.1-rc2 yesterday 64-bit on Snow Leopard. Much of the work in getting ghc to build 64-bit was done by Barney Stratford; the MacPorts ghc 6.10.4 has built successfully in 64 bit mode for a number of months. Until just a few weeks ago 6.12.x and HEAD wouldn't build 64-bit because of changes in ghci. These changes were in part to remove the limitation that modules loaded by ghci had to be located below the 2 GB address boundary. Unfortunately, they revealed code paths in ghc's Mach-O linker that were never tested. (See bug #4318. Other bugs may be partial duplicates; the tickets probably need to be examined to check which ones are distinct.) The good news is that the linker patches were done just in time for 7.0.1. You should be all set to try the release candidates on Snow Leopard 64-bit. I built my 7.0.1-rc2 using a 64 bit 6.10.4. My original 64-bit 6.10.4 was bootstrapped using a 32-bit 6.10.4 compiled on Leopard. Reports of trouble building the 7.0.1 release candidates using a 32-bit bootstrap compiler would be especially useful. Are there any instructions for building in this fashion from the source tarball or from VCS? Antoine Hi Antione, I used the tarball ghc-7.0.0.20101028.tar.bz2 and followed the directions in the README file: $ perl boot $ ./configure $ make (The perl boot command wasn't necessary, since I was building from a tarball instead of a darcs pull. However, it didn't cause any problems.) I haven't run a testsuite on the build yet. Perhaps someone from haskell HQ can tell me which version of the tests I should run on 7.0.1-rc2? Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Profiling bug in 6.10.4
On 3/31/10 11:44 AM, Ian Lynagh wrote: On Mon, Mar 22, 2010 at 02:54:26PM -0400, Gregory Wright wrote: Now they seem to both be correct. The key value is at the bottom of column 8. This should be 2.386e-1 (which means that 23.86 percent of the protons in the early universe end up as helium). So it seems that this is a problem either with 6.10.4, or with OS X. Quite strange. I will try to get 6.12 building on my machine to see if the problem persists. It would also be worth trying without the -optc-O3 and -optc-ffast-math flags, as the different code generated may confuse the mangler. If none of that helps, can you file a ticket please? If you can boil it down to a small self-contained testcase (in particular, removing the hmatrix dependency, if necessary by inlining code you need from it) that would make it easier to investigate. Thanks Ian Removing -optc-O3 and -optc-ffast-math did not help. In fact, I took at all of the ghc options I was passing and the problem is still there. I will try to reduce the failure to a self contained testcase. I don't use much from hmatrix --- aside from the LU solution for a matrix system, just basic matrix addition, subtraction, scaling and the dot product. Best, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Profiling bug in 6.10.4
Hi, I have a program (attached) that is relatively simple, but numerically intensive. It computes the abundances of the chemical elements generated by big-bang nucleosynthesis. At the moment, the executable takes no command line arguments, it simply runs the standard model. When I build the program without profiling, it produces the right answer. When I build it with profiling (runhaskell configure --enable-executable-profiling) it runs without error, but gives completely incorrect numerical results. I'm using ghc 6.10.4 built from source using MacPorts. The program is mostly self contained, but uses the hmatrix package to solve a linear system. Note also that the Vector type is hmatrix's Data.Packed.Vector and not the one from the more familiar vector package. I was wondering whether this profiling problem is known. Best Wishes, Greg Nsyn-0.5.tar.gz Description: GNU Zip compressed data ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Profiling bug in 6.10.4
Hi, On 3/22/10 10:22 AM, Gregory Wright wrote: Hi, I have a program (attached) that is relatively simple, but numerically intensive. It computes the abundances of the chemical elements generated by big-bang nucleosynthesis. At the moment, the executable takes no command line arguments, it simply runs the standard model. When I build the program without profiling, it produces the right answer. When I build it with profiling (runhaskell configure --enable-executable-profiling) it runs without error, but gives completely incorrect numerical results. I'm using ghc 6.10.4 built from source using MacPorts. The program is mostly self contained, but uses the hmatrix package to solve a linear system. Note also that the Vector type is hmatrix's Data.Packed.Vector and not the one from the more familiar vector package. I was wondering whether this profiling problem is known. Best Wishes, Greg The previously attach tarball was missing most of its contents, courtesy of my ham-fisted emacs technique. The tarball attached to this message has been tested by building and shows the problem mentioned above. -Greg Nsyn-0.6.tar.gz Description: GNU Zip compressed data ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Profiling bug in 6.10.4
Hi Krzysztof, On 3/22/10 2:42 PM, Krzysztof Skrzętnicki wrote: I got some results from GHC 6.12.1, Linux i686. In short: both profiling and normal run produce the same final results, but there are some differences. I don't know if they are valid or not. ./nsyn | tail 1080826.599 0.01 8.483e-157.612e-17.753e-52.517e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1134406.808 0.01 6.911e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1191190.672 0.01 5.615e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1251481.495 0.01 4.548e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1315638.396 0.01 3.671e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1384093.315 0.01 2.952e-157.612e-17.753e-52.515e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1457375.318 0.01 2.364e-157.612e-17.753e-52.515e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1535826.102 0.01 1.884e-157.612e-17.753e-52.515e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1619603.195 0.01 1.495e-157.612e-17.753e-52.514e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1709306.677 0.01 1.180e-157.612e-17.753e-52.514e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 ./nsyn-prof | tail 1080826.599 0.01 8.483e-157.612e-17.753e-52.517e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1134406.808 0.01 6.911e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1191190.672 0.01 5.615e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1251481.495 0.01 4.548e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1315638.396 0.01 3.671e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1384093.315 0.01 2.952e-157.612e-17.753e-52.515e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1457375.318 0.01 2.364e-157.612e-17.753e-52.515e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1535826.102 0.01 1.884e-157.612e-17.753e-52.515e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1619603.195 0.01 1.495e-157.612e-17.753e-52.514e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1709306.677 0.01 1.180e-157.612e-17.753e-52.514e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 Best regards Krzysztof Skrzętnicki 2010/3/22 Gregory Wrightgwri...@antiope.com: Hi, On 3/22/10 10:22 AM, Gregory Wright wrote: Hi, I have a program (attached) that is relatively simple, but numerically intensive. It computes the abundances of the chemical elements generated by big-bang nucleosynthesis. At the moment, the executable takes no command line arguments, it simply runs the standard model. When I build the program without profiling, it produces the right answer. When I build it with profiling (runhaskell configure --enable-executable-profiling) it runs without error, but gives completely incorrect numerical results. I'm using ghc 6.10.4 built from source using MacPorts. The program is mostly self contained, but uses the hmatrix package to solve a linear system. Note also that the Vector type is hmatrix's Data.Packed.Vector and not the one from the more familiar vector package. I was wondering whether this profiling problem is known. Best Wishes, Greg The previously attach tarball was missing most of its contents, courtesy of my ham-fisted emacs technique. The tarball attached to this message has been tested by building and shows the problem mentioned above. -Greg Now they seem to both be correct. The key value is at the bottom of column 8. This should be 2.386e-1 (which means that 23.86 percent of the protons in the early universe end up as helium). So it seems that this is a problem either with 6.10.4, or with OS X. Quite strange. I will try to get 6.12 building on my machine to see if the problem persists. -Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Profiling bug in 6.10.4
On OS X 10.5.9 with ghc 6.10.4 with no profiling I get : 1315638.396 0.01 3.671e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1384093.315 0.01 2.952e-157.612e-17.753e-52.515e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1457375.318 0.01 2.364e-157.612e-17.753e-52.515e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1535826.102 0.01 1.884e-157.612e-17.753e-52.515e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1619603.195 0.01 1.495e-157.612e-17.753e-52.514e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1709306.677 0.01 1.180e-157.612e-17.753e-52.514e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 but with profiling turned on I get 1301464.458 0.018.545e-19.002e-1 3.312e-12 5.820e-24 6.174e-24 1.367e-34 1.505e-58 3.780e-70 3.586e-70 7.960e-82 1379801.447 0.018.545e-19.293e-1 3.312e-12 5.820e-24 6.174e-24 1.411e-34 1.505e-58 3.780e-70 3.586e-70 7.960e-82 1462853.640 0.018.545e-19.596e-1 3.312e-12 5.820e-24 6.174e-24 1.458e-34 1.505e-58 3.780e-70 3.586e-70 7.960e-82 1550904.850 0.018.545e-19.947e-1 3.312e-12 5.820e-24 6.174e-24 1.511e-34 1.505e-58 3.780e-70 3.586e-70 7.960e-82 1644255.972 0.018.545e-1 1.032e0 3.312e-12 5.820e-24 6.174e-24 1.568e-34 1.505e-58 3.780e-70 3.586e-70 7.960e-82 1743226.010 0.018.545e-1 1.074e0 3.312e-12 5.820e-24 6.174e-24 1.631e-34 1.505e-58 3.780e-70 3.586e-70 7.960e-82 It's not just a matter of some addition numerical inaccuracy; the numbers are off by orders of magnitude. -Greg On 3/22/10 2:42 PM, Krzysztof Skrzętnicki wrote: I got some results from GHC 6.12.1, Linux i686. In short: both profiling and normal run produce the same final results, but there are some differences. I don't know if they are valid or not. ./nsyn | tail 1080826.599 0.01 8.483e-157.612e-17.753e-52.517e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1134406.808 0.01 6.911e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1191190.672 0.01 5.615e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1251481.495 0.01 4.548e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1315638.396 0.01 3.671e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1384093.315 0.01 2.952e-157.612e-17.753e-52.515e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1457375.318 0.01 2.364e-157.612e-17.753e-52.515e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1535826.102 0.01 1.884e-157.612e-17.753e-52.515e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1619603.195 0.01 1.495e-157.612e-17.753e-52.514e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1709306.677 0.01 1.180e-157.612e-17.753e-52.514e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 ./nsyn-prof | tail 1080826.599 0.01 8.483e-157.612e-17.753e-52.517e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1134406.808 0.01 6.911e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1191190.672 0.01 5.615e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1251481.495 0.01 4.548e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1315638.396 0.01 3.671e-157.612e-17.753e-52.516e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1384093.315 0.01 2.952e-157.612e-17.753e-52.515e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1457375.318 0.01 2.364e-157.612e-17.753e-52.515e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1535826.102 0.01 1.884e-157.612e-17.753e-52.515e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1619603.195 0.01 1.495e-157.612e-17.753e-52.514e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 1709306.677 0.01 1.180e-157.612e-17.753e-52.514e-7 1.566e-52.387e-1 3.089e-14 6.337e-11 5.791e-11 5.665e-16 Best regards Krzysztof Skrzętnicki 2010/3/22 Gregory Wrightgwri...@antiope.com: Hi, On 3/22/10 10:22 AM, Gregory Wright wrote
ANNOUNCE: haskell-platform on MacPorts
Hi, The haskell-platform, version 2009.2.0.2, is now available from MacPorts. For those unfamiliar with MacPorts, it a build-from-source system for OS X similar to the port system used in BSD distributions. More information is available from http://macports.org. Once MacPorts is installed, you can build the haskell platform by typing sudo port install haskell-platform On a reasonably fast MacBook, this takes an hour and a half to two hours. If you want to watch the excitement scroll past, try sudo port -d install haskell-platform The platform contains an updated port of ghc-6.10.4 which now builds automagically on 32 and 64 bit Snow Leopard. (It can also be forced to build 32 bit on a 64 bit Snow Leopard by setting the build_arch variable to i386 in the macports.conf file.) The 64 bit port was cribbed from the excellent work of Barney Stratford for fink. Thanks as well to Marco Comini, Tom Hutchinson, Ian Lynagh, John Peterson, Ryan Schmidt and Falk Schramm for their help. Best Wishes, Greg Wright -- Gregory Wright Antiope Associates LLC 18 Clay Street Fair Haven, New Jersey 07704 USA gwri...@antiope.com +1 (732) 924-4549 +1 (732) 345-8378 [fax] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc ftp site
Hi, Could someone tell me who is in charge of the ghc ftp site these days? I need to upload a bootstrap compiler to build MacPort's ghc on Snow Leopard and the permissions of the 6.10 - 6.1 directories have changed. I no longer can write there. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.4 Release Candidate 1
Good rc1 build on OS X 10.5.7 (Leopard/intel). Couldn't run the 6.10.3 testsuite all the way through. Failed with things like = getGroupEntryForName(normal) cd ../../../libraries/unix/tests '/opt/local/var/macports/build/_Users_gwright_src_macports-trunk_dports_lang_ghc-beta/work/ghc-6.10.3.20090628/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -o getGroupEntryForName getGroupEntryForName.hs -package unix getGroupEntryForName.comp.stderr 21 cd ../../../libraries/unix/tests ./getGroupEntryForName/dev/null getGroupEntryForName.run.stdout 2getGroupEntryForName.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: getGroupEntryForName: thisIsNotMeantToExist: getGroupEntryForName: does not exist (no group name) Should I be running a different version of the tests? Best Wishes, Greg -- Gregory Wright Antiope Associates LLC 18 Clay Street Fair Haven, New Jersey 07704 USA gwri...@antiope.com +1 (732) 924-4549 +1 (732) 345-8378 [fax] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.10.3-pre on OS X 10.5.6
Hi, I built ghc-6.10.2.20090504 on OS X 10.5.6 (Intel). The build succeeded, and the results of running the 6.10.2 (release) testsuite were: OVERALL SUMMARY for test run started at Wed May 6 04:21:54 EDT 2009 2413 total tests, which gave rise to 12919 test cases, of which 0 caused framework failures 2489 were skipped 10033 expected passes 301 expected failures 0 unexpected passes 96 unexpected failures Unexpected failures: 2469(ghci) 2816(ghci) DoParamM(normal) jl_defaults(ghci) jules_xref(ghci) jules_xref2(ghci) launchbury(ghci) lex(ghci) mod133(normal) num009 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) reify (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) rittri(ghci) signals002(ghci,ghci) signals004 (ghci ,threaded1,threaded2,profthreaded,ghci,threaded1,threaded2,profthreaded) tc183(normal,optc,hpc,optasm,profc,profasm) tc217(normal,optc,hpc,optasm,profc,profasm) tc220(normal,optc,hpc,optasm,profc,profasm) tc223(normal,optc,hpc,optasm,profc,profasm) tc232(normal,optc,hpc,optasm,profc,profasm) tcfail126(normal) tree (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) (I assume that I should be testing with the latest released testsuite in the absence of a snapshot. Is that true?) Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1
I built ghc-6.10.1.20090314 on OS X 10.5.6 (Intel) using ghc 6.8.2 as a bootstrap compiler. The build was done using the MacPorts infrastructure. Summary test results: OVERALL SUMMARY for test run started at Tue Mar 17 15:31:38 EDT 2009 2334 total tests, which gave rise to 12487 test cases, of which 0 caused framework failures 2460 were skipped 9709 expected passes 258 expected failures 0 unexpected passes 60 unexpected failures Unexpected failures: 2469(ghci) apirecomp001(normal) bits (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) conc049(hpc) conc068(normal) derefnull(profc,profthreaded) divbyzero(profc,profthreaded) genUpTo (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) length001(optc,hpc,optasm,profc,profasm,threaded2,profthreaded) num009 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) num012 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) signals002(ghci) signals004(ghci,threaded1,threaded2,profthreaded) I haven't looked at the errors in detail, but generally the release candidate seems OK. BTW, a test target will be added to MacPorts's portfile for the 6.10.2 release, which will let you run the test suite by typing sudo port test ghc and if you then install the tested build, a record of the test will be saved in $PREFIX/share/ghc-version/. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1
Hi Thomas, On Mar 18, 2009, at 10:03 AM, Thomas Schilling wrote: There should be a file called testlog somewhere, either at the toplevel or within the tests directory. Could you search for apirecomp001 and send me the test output from running that test. I can't reproduce this failure when running it manually even though I'm on OS X, too. I get: Running ./ghc-api/apirecomp001/all.T = apirecomp001(normal)cd ./ghc-api/apirecomp001 $MAKE -s --no- print-directory apirecomp001/dev/null apirecomp001.run.stdout 2apirecomp001.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: ld warning: atom sorting error for _ghczm6zi10zi1zi20090314_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi1zi20090314_LibFFI_Czuffizucif_closure_tbl in /opt/local/ var/macports/build/_Users_gwright_src_macports-trunk_dports_lang_ghc- beta/work/ghc-6.10.1.20090314/compiler/dist-stage2/build/ libHSghc-6.10.1.20090314.a(LibFFI.o) ld warning: atom sorting error for _ghczm6zi10zi1zi20090314_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi1zi20090314_LibFFI_Czuffizucif_closure_tbl in /opt/local/ var/macports/build/_Users_gwright_src_macports-trunk_dports_lang_ghc- beta/work/ghc-6.10.1.20090314/compiler/dist-stage2/build/ libHSghc-6.10.1.20090314.a(LibFFI.o) make[2]: myghc: Command not found make[2]: *** [apirecomp001] Error 127 *** unexpected failure for apirecomp001(normal) Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Segmentation fault trying to build ghc 6.10.1 using macports, Mac OS X 10.5, PPC
Hi David, On Feb 2, 2009, at 4:48 AM, Christian Maeder wrote: David Menendez wrote: I'm trying to upgrade GHC to 6.10.1 using macports on a PowerBook G4 running OS X 10.5.5. From what I can tell, I'm getting a segmentation fault from cabal-bin. On PPC leopard you need to update to XCode 3.1 http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX http://hackage.haskell.org/trac/ghc/ticket/2887 HTH Christian It would be very helpful to know if this solves the problem for you. I've had reports of similar failures on 10.4, but have not been able to reproduce them on a ppc/10.4 machine or a ppc/10.5 machine. Even with Xcode 3.0, it seems as if not everyone gets tagged by the error. Greg This is possibly related to http://trac.macports.org/ticket/15142 and http://hackage.haskell.org/trac/ghc/ticket/2380. cd extensible-exceptions /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ cabal-bin /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ bootstrapping.conf configure --distpref=dist-bootstrapping --with-compiler=/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc --with-hc-pkg=/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg --package-db=/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ bootstrapping.conf.tmp /bin/sh: line 1: 19203 Segmentation fault /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ cabal-bin /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ bootstrapping.conf configure --distpref=dist-bootstrapping --with-compiler=/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc --with-hc-pkg=/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg --package-db=/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ bootstrapping.conf.tmp make[1]: *** [bootstrapping.conf] Error 139 make: *** [stage1] Error 2 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Preferred gcc for use with ghc
Hi, What is the preferred gcc to use with ghc 6.10.1? I'm starting the long and doubtless slow process of putting together a more user friendly (and binary distributable) ghc distribution to be built using MacPorts. The guidance about gcc on the wiki is vague. Is there a best choice? Or at least some versions to be avoided? Best, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
Hi Jason, On Nov 21, 2008, at 8:09 AM, Jason Dagit wrote: On Wed, Nov 19, 2008 at 1:28 AM, Manuel M T Chakravarty [EMAIL PROTECTED] wrote: Jason Dagit: On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty [EMAIL PROTECTED] wrote: Ian Lynagh: On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH wrote: On 2008 Nov 4, at 20:26, Jason Dagit wrote: On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty [EMAIL PROTECTED] wrote: Are you sure it does deinstall the 6.8 compiler? After installing 6.10, there should be a 608/ and a 610/ directory. This certainly happens on my Mac and I am not aware of an option to change that behaviour. I expect if you used the OSX installer then /Library/Receipts is screwing you (it wipes the old files listed in the .bom file). Try finding and removing the receipt directory and bom file before installing. The only file I can see that looks relevant is /Library/Receipts/boms/ org.haskell.glasgowHaskellCompiler.ghc.pkg.bom Wouldn't removing it make uninstall impossible? In fact, if you did manage to get 2 versions installed, how would /Library/Frameworks/GHC.framework/Tools/Uninstaller know which version to uninstall? Wouldn't it only know how to uninstall the version it came with? I'd suggest that the overlapping file Uninstaller could be why the older version gets removed, but that wouldn't explain why Manuel can install both at once. A current limitation of the MacOS package system is that it does not support uninstalling of packages; cf http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#/ /apple_ref/doc/uid/1145i-CH6-DontLinkElementID_29 This is not a big drama on MacOS, as MacOS encourages the distribution of software packages as bundles: http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html This essentially means that instead of sprinkling files all over the file system (as is common in other OSes), MacOS applications and frameworks (Mac-speak for libraries) are kept in a single directory. Uninstalling then means doing an rm -rf on that directory. Unfortunately, some applications (including GHC and Apple's Xcode IDE) can't be entirely contained in a single directory. In the case of GHC, we want symlinks in /usr/bin. The established way of uninstalling such applications is by supplying an Uninstaller script, just as I did for GHC. (Apple does the same for Xcode.) The purpose of the Uninstaller script is too completely remove GHC.framework from a machine - not just to remove one version. In fact, if more than one version of GHC is installed, the Uninstaller will refuse to run and require the manual removal of all versions, but the current (easily achieved by a rm -rf /Library/Frameworks/GHC.framework/Versions/version). The main feature of the Uninstaller script is to get rid of all symlinks pointing into GHC.framework. The framework itself is just deleted by a rm -rf as expected. (It also removes the above mentioned receipt file.) So, to directly answer the above questions: * The package manger (which uses the receipts) can't uninstall and the uninstaller script doesn't need the receipt. So, even after deleteing the receibt, you can still uninstall. * The Uninstaller can uninstall any version (at least as long as no symlinks are put into new directories outside of the bundle that the Uninstaller doesn't know about). Is there an update on this thread? I would still like to have my cake and eat it too, meaning ghc 6.8.3 and ghc 6.10.1. As far as I know the installer hasn't been updated and if I try again I will lose my copy of 6.8.3. Sorry, but for the moment, my (rather limited knowledge) of the MacOS packaging system is exhausted, and currently I don't have the time to search the web or experiment to try to learn more. It would be helpful to have the input of somebody who has more experience with MacOS packages. Manuel Okay. That's fine, the OSX installer system sounds odd. I don't want to fight with it myself. I just want to upgrade ghc and I was getting pressure to do so and I tried the .tar.bz version, but I had some annoying experiences that I can share. So, the page here: http://www.haskell.org/ghc/download_ghc_6_10_1.html#macosxintel Has only this as installation instructions: This is a binary distribution for Mac OS X 10.5 (Leopard), prepared by Christian Maeder. It needs libedit.2.dylib, libncurses.5.dylib and libgmp.3.dylib under /opt/local/lib/. I had no idea how to do the install or how to satisfy the requirements. By pestering others I learned that you install libraries into /opt/local using MacPorts. The next challenge was learning what to do with the .tar.bz file once it was downloaded. I found an INSTALL file inside the tarball with some instructions thankfully. I wish the download page said something about
Re: GHC on powerpc (OS X): segmentation fault
Hi Chrisitian, On Nov 11, 2008, at 7:19 AM, Christian Maeder wrote: Chris Kuklewicz wrote: Christian Maeder wrote: I can offer a Tiger PPC built that works for me: (linked against /opt/local/lib/libgmp.dylib) But the filename says -i386- so I suspect it is not a powerpc build. Sorry, the link is: http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.10.1-powerpc-apple-darwin.tar.bz2 Christian I'll try using your binary compiler as a bootstrap compiler for the macports' ppc builds. Should have something ready for testing in a day or two. Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: has anyone built pandoc with MacPorts ?
Hi Denis, I haven't built pandoc yet --- I didn't do the port --- but I'll have a go at it tonight and let you know what I find. BTW, did you run $ sudo port selfupdate before starting to make sure you had the latest Portfiles for everything? Best Wishes, Greg On Oct 10, 2008, at 4:45 PM, denis wrote: Greg, folks, port install ghc worked after 7 hours or so, but then sudo port -v install hs-ghc-paths (on which pandoc apparently depends) = # from: sudo port -v install hs-ghc-paths # run: 10 Oct 2008 22:35 in /opt/local Denis.local mac 10.4.11 ppc --- Configuring hs-ghc-paths Setup.hs:7:7: Could not find module `Distribution.Simple.PackageIndex': Use -v to see a list of the files searched for. Error: Target org.macports.configure returned: shell command cd / opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_devel_hs-ghc-paths/work/ghc- paths-0.1.0.5 runhaskell Setup configure --ghc --prefix=/opt/ local returned error 1 Command output: Setup.hs:7:7: Could not find module `Distribution.Simple.PackageIndex': Use -v to see a list of the files searched for. Warning: the following items did not execute (for hs-ghc-paths): org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.install Error: Status 1 encountered during processing. Has anyone ever built pandoc with MacPorts ? Would appreciate your help. cheers -- denis ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: has anyone built pandoc with MacPorts ?
Hi, On Oct 10, 2008, at 4:45 PM, denis wrote: Greg, folks, port install ghc worked after 7 hours or so, but then sudo port -v install hs-ghc-paths (on which pandoc apparently depends) = # from: sudo port -v install hs-ghc-paths # run: 10 Oct 2008 22:35 in /opt/local Denis.local mac 10.4.11 ppc --- Configuring hs-ghc-paths Setup.hs:7:7: Could not find module `Distribution.Simple.PackageIndex': Use -v to see a list of the files searched for. Error: Target org.macports.configure returned: shell command cd / opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_devel_hs-ghc-paths/work/ghc- paths-0.1.0.5 runhaskell Setup configure --ghc --prefix=/opt/ local returned error 1 Command output: Setup.hs:7:7: Could not find module `Distribution.Simple.PackageIndex': Use -v to see a list of the files searched for. Warning: the following items did not execute (for hs-ghc-paths): org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.install Error: Status 1 encountered during processing. Has anyone ever built pandoc with MacPorts ? Would appreciate your help. cheers -- denis Pandoc built fine for me on Mac OS X 10.5.5/intel with ghc 6.8.3, hs- ghc-paths 0.1.0.5 and haddock 2.2.2. What version of the ghc port are you using (i.e., the output of $ port info ghc ? Also, do you have more than one version of cabal on your system? Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
Hi Manuel, On Aug 14, 2008, at 9:12 PM, Manuel M T Chakravarty wrote: Moreover, as I wrote a few times before, some reasons for switching in the first place are invalidated by not having the core libraries in git, too. For example, one complaint about darcs is that it either doesn't build (on the Sun Solaris T1 and T2 machines) or is buggy (on Mac OS with MacPorts), and hence people have trouble getting the sources out of darcs in the first place. How is that going to be addressed if some crucial code still needs to be obtained using darcs? Regarding darcs on OS X from MacPorts, I am not aware (or have been sent any bug reports) that there are problems with the latest darcs-2.0.0 port. Is there something that I should know (and try to fix)? The latest port defaults to wget instead of libcurl since I have noticed darcs spinning endlessly when using libcurl. I haven't had time to dtrace what is going on but I'm guessing the underlying problem is likely some misunderstanding of the signal handling API or some corner case of blocking/nonblocking IO. -Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANN: prof2dot, version 0.4.1
I am pleased to announce the release of prof2dot version 0.4.1, a graphical profiling tool for use with GHC. The program is a filter that takes the profiling output generated by running a GHC-compiled program with the +RTS -px -RTS option and turns it into a dot file. (The dot format is a textual representation of a directed or undirected graph.) The dot file can rendered in any format supported by Graphviz's dot program, and the file itself can be post-processed or edited to adjust the layout. The new release fixes a number of bugs and has some significant improvements in its internal organization over the previous 0.3.1 (Premature Optimizations 'r' Us) release. Version 0.4.1 (Triumph of Hope Over Experience) defaults to generating a call graph colored by number of entries into each call center. There is now an option to annotate the graph edges with the triple of (cost center entries, ticks, allocations). Module names are also given in each cost center. The latest version has been tested on the profiling output of some moderately large programs, e.g., the profile produced by a darcs get of the entire ghc repository: $ darcs get http://darcs.haskell.org/ghc +RTS -px -RTS There is also better error reporting of parser errors and consistency checking of the internal graph data structure. If anyone comes across a parse failure or an assertion failure, please report it to the author. The dot program from the graphviz tools is required to render the output of prof2dot. Very large graphs, or graphs with extensive annotations, can exceed the capabilities of dot. Prof2dot is available from Hackage in the development category. -Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: *BSD support in 6.8.3
Hi, On May 29, 2008, at 11:19 AM, Simon Marlow wrote: Ok, I've now modified the patch and attached a new version to the ticket: http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch *BSD folks please test. I built the 20080529 snapshot with this patch and my light testing of ghci showed no problems (FreeBSD 7.0/x86_64). I will built it again tonight in a darcs checkout and run the test suite. I should be able to send back any tweaks to the patch in the next two days. -Greg I've built ghc 6.8.x from the darcs repository (checked out on 30 May) with the 2013.patch on FreeBSD 7.0/x86_64. As far as ghci is concerned, it seems to work and passes almost all of the tests. However, there are many unexpected failures in the testsuite, almost all apparently coming from failures to find mkstemp, mknod and S_IFDIR in header files. Either some conditional includes are broken in ghc or FreeBSD 7.0 moved some things. I'll have a look tomorrow. -Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: *BSD support in 6.8.3
Hi Simon, On May 29, 2008, at 11:19 AM, Simon Marlow wrote: Ok, I've now modified the patch and attached a new version to the ticket: http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch *BSD folks please test. I built the 20080529 snapshot with this patch and my light testing of ghci showed no problems (FreeBSD 7.0/x86_64). I will built it again tonight in a darcs checkout and run the test suite. I should be able to send back any tweaks to the patch in the next two days. -Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: *BSD support in 6.8.3
Hi Simon, On May 28, 2008, at 5:05 AM, Simon Marlow wrote: Hi Folks, 6.8.3 is nearing release, and we have an outstanding bug affecting the GHCi on the BSDs: http://hackage.haskell.org/trac/ghc/ticket/2013 We need someone to help out with this. The patch in the ticket apparently works, but can't be committed as is because it isn't correctly #ifdef'd and will presumably break other platforms. Also it needs to be tested on OpenBSD/NetBSD in addition to FreeBSD. I don't have access to a *BSD machine right now, and I don't have the time available to set one up. If someone can donate a temporary account then that would be helpful, but most helpful would be if someone could work with us to get this bug fixed in time for 6.8.3 (i.e. the next few days). Otherwise, we have to release with the bug still in, which would be bad. Cheers, Simon I have a FreeBSD 7.0/x86_64 machine I can test this on. Should the patch be applied to the 6.8.3 release candidate tarball, or just the head of the 6.8.x branch? Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: ghc 6.8.2 from MacPorts
Hi Wouter, On May 1, 2008, at 11:50 AM, Wouter Swierstra wrote: On 1 May 2008, at 13:59, Gregory Wright wrote: I've patched MacPorts' ghc-6.8.2 to include the -no-user-package-conf flag. Wouter, could you check if this fixes the problem you had? I tried a port selfupdate and port clean --all ghc, followed by a port install ghc. I ran into the error below (seems like another file-locking bug). I Bjorn's advice (getting rid of the .ghc directory) - the build went through smoothly. I'm not sure what's going on here. Hope this helps, Wouter --- Fetching ghc snip '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/ doc/ghc/libraries/$pkg' ; \ fi Installing: /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib/Cabal-1.2.3.0 installPackage: copyFile: resource busy (file is locked) make[1]: *** [install.library.Cabal] Error 1 make: *** [install] Error 1 Error: Status 1 encountered during processing. Hmmm. If I understand correctly, doing a port selfupdate and port clean --all gave a locking bug, but after you deleted .ghc, everything worked properly? The locking bug looks like #2134, which is fixed by a patch in Macports' ghc-6.8.2. The patch strictifies a readFile invocation in Cabal, so probably you were still using the out-of-date Cabal installed as a user package. There are two possible causes: either -no-user-package-conf has a bug and doesn't always work right, or you still have the previous revision of the ghc port, before the -no- user-package-conf patch. The latter can happen if there was some problem on the Macports server that delayed indexing the new portfile and serving it as a selfupdate. Can you do a port installed ghc and verify that you have revision 3? Best WIshes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: ghc 6.8.2 from MacPorts
On Apr 26, 2008, at 4:58 PM, Ian Lynagh wrote:
On Thu, Apr 24, 2008 at 09:25:26AM -0400, Gregory Wright wrote:
I'll see if I can come up with a patch to the build system that
avoids
this.
I think that this was actually done a while ago:
[pass -no-user-package-conf to ghc-inplace
Simon Marlow [EMAIL PROTECTED]**20080104162840] {
Thanks
Ian
I've patched MacPorts' ghc-6.8.2 to include the -no-user-package-conf
flag. Wouter, could you check if this fixes the problem you had?
bw,
Greg
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: ghc 6.8.2 from MacPorts
Hi Björn, On Apr 24, 2008, at 6:41 AM, Bjorn Bringert wrote: On Thu, Mar 6, 2008 at 7:57 PM, Wouter Swierstra [EMAIL PROTECTED] wrote: Hi Greg, Thanks again for maintaining ghc in macports! I tried installing ghc through macports. Unfortunately, the build failed with the following error message below. I'd be happy to send you a complete log, if you think it would help. Many thanks, Wouter main/ParsePkgConf.hs:296:35: Not in scope: `extraLibraries' main/ParsePkgConf.hs:297:35: Not in scope: `extraGHCiLibraries' main/ParsePkgConf.hs:298:35: Not in scope: `includeDirs' main/ParsePkgConf.hs:299:35: Not in scope: `includes' main/ParsePkgConf.hs:300:35: Not in scope: `hugsOptions' main/ParsePkgConf.hs:301:35: Not in scope: `ccOptions' main/ParsePkgConf.hs:302:35: Not in scope: `ldOptions' main/ParsePkgConf.hs:303:35: Not in scope: `frameworkDirs' main/ParsePkgConf.hs:304:35: Not in scope: `frameworks' main/ParsePkgConf.hs:305:35: Not in scope: `haddockInterfaces' main/ParsePkgConf.hs:306:35: Not in scope: `haddockHTMLs' main/ParsePkgConf.hs:307:34: Not in scope: `depends' main/ParsePkgConf.hs:320:43: Not in scope: `depends' ghc: 73406780 bytes, 11 GCs, 759125/1814528 avg/max bytes residency (3 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.09 MUT (0.13 elapsed), 0.06 GC (0.07 elapsed) :ghc make[2]: *** [stage2/main/ParsePkgConf.o] Error 1 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 Warning: the following items did not execute (for ghc): org.macports.activate org.macports.build org.macports.destroot org.macports.install Error: Status 1 encountered during processing. I got the same error when trying to install ghc 6.8.2 from MacPorts on OS X 10.4.11/Intel. It seems like the stage2 build is picking up the wrong version of Cabal from my user packages left over from a previous GHC 6.8.2 installation. Deleting ~/.ghc fixes the problem. Maybe the GHC build should be changed to make sure that it doesn't use user packages? Björn I'll see if I can come up with a patch to the build system that avoids this. BTW, what version the Cabal in your user packages? I was never able to reproduce this myself --- I probably didn't stumble upon the right (i.e., wrong) combination of cabals. bw, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: prof2dot, a graphical profiling tool
Hi Cristian, On Apr 1, 2008, at 11:03 AM, Cristian Perfumo wrote: I was wondering if it handles per-thread information when you have more than one thread involved. (Actually the question is not related to the graphical tool, but the announcement triggered it). The prof2dot tool only knows about the information that is in the profiling dump file. IIRC, cost centers are not associated with threads in this file. (The format isn't documented, but it is not hard to figure out, given a look at the code that generates it.) Is recording the thread in which a cost was incurred really helpful? If it is, I could look into adding it. But are you more interested in a graphical representation of thread execution --- which threads are executing and when? You should check if any of the old Glasgow Parallel Haskell tools are close to what you want. If so, it might be less work to resurrect one of those. Best Wishes, Greg Best. Cristian 2008/3/8 Gregory Wright [EMAIL PROTECTED]: I am pleased to announce the first release of prof2dot, a graphical profiling tool for use with GHC. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Success report: Leopard powerpc
Excellent news. Thanks to you and Christian for trying it out. -Greg On Mar 17, 2008, at 4:12 PM, Chris Kuklewicz wrote: I used both ghc-6.6.1 and macports to create a working ghc-6.8.2 on OS X 10.5.2 on a powerpc G4 laptop. ___ 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: ANN: ghc 6.8.2 from MacPorts
Hi Christian, On Mar 13, 2008, at 7:10 AM, Christian Maeder wrote: I was able to build ghc 6.8.2 on Leopard/ppc using the patch from http://hackage.haskell.org/trac/ghc/ticket/1958 (also below) Could you try if it works for you, too? I forgot to mention, that I had to build a bootstrapping compiler on pcc tiger with this patch first. I'll build a bootstrap compiler with this patch today so we can give it a try. Thanks! -Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc's trac is wedged
Hi, This morning (13 March 2008) the ghc trac wedged reporting Trac detected an internal error: with the python traceback Traceback (most recent call last): File /var/lib/python-support/python2.4/trac/web/main.py, line 387, in dispatch_request dispatcher.dispatch(req) File /var/lib/python-support/python2.4/trac/web/main.py, line 237, in dispatch resp = chosen_handler.process_request(req) File /var/lib/python-support/python2.4/trac/web/auth.py, line 100, in process_request self._do_login(req) File /var/lib/python-support/python2.4/trac/web/auth.py, line 139, in _do_login VALUES (%s, %s, %s, %s), (cookie, remote_user, File /var/lib/python-support/python2.4/trac/db/util.py, line 50, in execute return self.cursor.execute(sql_escape_percent(sql), args) File /usr/lib/python2.4/site-packages/sqlite/main.py, line 237, in execute self.con._begin() File /usr/lib/python2.4/site-packages/sqlite/main.py, line 503, in _begin self.db.execute(BEGIN) OperationalError: database is locked Please let me know if there is a more direct way to report failures such as this one, instead of posting to the list. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: ghc 6.8.2 from MacPorts
Hi Wouter, On Mar 6, 2008, at 12:57 PM, Wouter Swierstra wrote: Hi Greg, Thanks again for maintaining ghc in macports! I tried installing ghc through macports. Unfortunately, the build failed with the following error message below. I'd be happy to send you a complete log, if you think it would help. Many thanks, Wouter main/ParsePkgConf.hs:296:35: Not in scope: `extraLibraries' main/ParsePkgConf.hs:297:35: Not in scope: `extraGHCiLibraries' main/ParsePkgConf.hs:298:35: Not in scope: `includeDirs' main/ParsePkgConf.hs:299:35: Not in scope: `includes' main/ParsePkgConf.hs:300:35: Not in scope: `hugsOptions' main/ParsePkgConf.hs:301:35: Not in scope: `ccOptions' main/ParsePkgConf.hs:302:35: Not in scope: `ldOptions' main/ParsePkgConf.hs:303:35: Not in scope: `frameworkDirs' main/ParsePkgConf.hs:304:35: Not in scope: `frameworks' main/ParsePkgConf.hs:305:35: Not in scope: `haddockInterfaces' main/ParsePkgConf.hs:306:35: Not in scope: `haddockHTMLs' main/ParsePkgConf.hs:307:34: Not in scope: `depends' main/ParsePkgConf.hs:320:43: Not in scope: `depends' ghc: 73406780 bytes, 11 GCs, 759125/1814528 avg/max bytes residency (3 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.09 MUT (0.13 elapsed), 0.06 GC (0.07 elapsed) :ghc make[2]: *** [stage2/main/ParsePkgConf.o] Error 1 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 Warning: the following items did not execute (for ghc): org.macports.activate org.macports.build org.macports.destroot org.macports.install Error: Status 1 encountered during processing. This is odd. What platform (intel/ppc and OS X version) are you running on? A complete log would help too. The output of # sudo port -dv destroot ghc dest.log 21 is good. You will probably want to compress the log file before sending. One thing you might try is to ensure that you have no failed build lying around by running # sudo port clean ghc # sudo port install ghc The combination of ghc Makefiles and MacPorts infrastructure is not able to recover from a failed or interrupted build. You need to clean up and start over. You should also clean before recording the log. Best, greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANN: prof2dot, a graphical profiling tool
I am pleased to announce the first release of prof2dot, a graphical profiling tool for use with GHC. While GHC has in the past worked with graphical profiling tools, they have been heavyweight and/or proprietary. Prof2dot is a simple tool for converting profiling information into a graphical format, released under a BSD3 license. It is simple because it offloads all of the work of rendering the graph onto Graphviz. So you need to install the Graphviz tools in order to use it. The program is a filter that takes the profiling output generated by running a GHC-compiled program with the +RTS -px -RTS option and turns it into a dot file. (The dot format is a textual representation of a directed or undirected graph.) The dot file can rendered in any format supported by Graphviz's dot program, and the file itself can be post-processed or edited to adjust the layout. Features of prof2dot: * display either the call graph (default) or the call tree, * colorize by cost center count, time or allocations, * group cost centers in the same module. Prof2dot installs as a typical caballized application. Running prof2dot -? from the command line will give a short summary of how to use the program and its options. Rendering very large graphs can exceed the internal resource limits of dot. You may have to compile your own version of the Graphviz tools with higher limits to handle these cases. A example of a colorized profile of a medium sized project is shown on our company's web site: http://antiope.com/downloads.html. Click on the small image to download a pdf of the complete profile graph. Prof2dot is available from hackage or the link given above. -Greg___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: ghc 6.8.2 from MacPorts
On Mar 5, 2008, at 4:21 AM, Jinwoo Lee wrote: Thank you! But ghc has disappeared from MacPorts SW list. Only ghc-devel can be seen. Please look into it. ghc vanished from the distribution server for a few hours yesterday because of a unanticipated corner case in the indexing script. (The server runs Leopard/ppc, and incorrectly rejected ports that correctly reported that they do not run on Leopard/ppc.) A workaround was implemented and it is now available. MacPorts helps debug ghc and ghc helps debug MacPorts! -Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANN: ghc 6.8.2 from MacPorts
After what many would consider an unconscionable delay, I am happy to announce that ghc 6.8.2 is available from MacPorts. The ghc 6.8.2 port is available for Tiger/ppc, Tiger/intel and Leopard/ intel. Users with Leopard/ppc are out of luck until for now, for reason discussed earlier on this list. In partial recompense for their patience, users will get a ghc with more patches than any previous MacPorts ghc. A few notes: The file locking bugs #1992 and #2134 are fixed. Bug #1992 was a simple lock logic error and should be killed dead. Bug #2134 was the result of a lazy readFile holding a lock for an unpredictable time. There may be more cases like this one, and I would appreciate a note from anyone who come across a lock error during building. Users on Leopard/intel must upgrade to 10.5.2 to avoid an OS bug which under unusual circumstances would repeatably (and mysteriously) crash the build. This was first noticed running the building in an eshell under Aquamacs. Archives were built without tables of contents because ranlib wasn't being run or wasn't running to completion. Builds in the usual Terminal.app didn't trip over this bug. OpenGL support is built by default. It can be turned off using the no_opengl variant. OpenAL support is disabled. Apple's OpenAL framework lacks ALUT support (needed for the ghc binding) but has name clashes with the freealut library from the OpenAL.org website. Fixing this is probably straightforward. If someone is interested, I can give them some pointers on getting started. MacPort's ghc ought to always link with the correct libgmp (the one provided by the gmp port). The latest versions of alex, happy, haddock and hs-Edison are also available. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: patch applied (cabal): make rawSystemStdout put its temp files in the temp dir rather than cwd
Hi Duncan, (Cross-posting to ghc-users since some of the issues were brought up there.) On Dec 2, 2007, at 5:04 PM, Duncan Coutts wrote: Sun Dec 2 14:06:20 PST 2007 Duncan Coutts [EMAIL PROTECTED] * make rawSystemStdout put its temp files in the temp dir rather than cwd Should fixe reported wierdness with finding program version numbers M ./Distribution/Simple/Utils.hs -2 +4 I saw this problem when trying to build 6.8.1 on a mac (Leopard/Intel) using 6.4 to build compiler. I edited rawSystemStdout to put the tmp files directory in /tmp instead of using getTemporaryDirectory. On this combination of compilers, moving the temporary file did not fix the problem of finding the program version number. The underlying error was that the temp file was reported to still be locked. Building 6.8.2 with another 6.8.2 eliminated the program version problem, but I have seen two other intermittent errors which seem to be related. (Reported in trac as issue #1992.) Building 6.8.2 with 6.8.2 using the MacPorts infrastructure, I get this error about half the time: ../compiler/stage1/ghc-inplace -M -optdep-f -optdep.depend-BASE - osuf o -I../includes -H16m -O -I/opt/local/include -I/usr/include -L/ opt/local/lib -L/usr/lib -iutils -ibasicTypes -itypes -ihsSyn - iprelude -irename -itypecheck -ideSugar -icoreSyn -ivectorise - ispecialise -isimplCore -istranal -istgSyn -isimplStg -icodeGen -imain -iprofiling -iparser -icprAnalysis -indpFlatten -iiface -icmm - inativeGen -ighci -Wall -fno-warn-name-shadowing -fno-warn-orphans - Istage2 -package hpc -package bytestring -DGHCI -package template- haskell -DGHCI_TABLES_NEXT_TO_CODE -package readline -DUSE_READLINE - cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -H16M '- #include cutils.h' -package-name ghc-6.8.2 -fgenerics basicTypes/ BasicTypes.lhs basicTypes/DataCon.lhs basicTypes/Demand.lhs basicTypes/ Id.lhs basicTypes/IdInfo.lhs basicTypes/Literal.lhs basicTypes/ MkId.lhs basicTypes/Module.lhs basicTypes/Name.lhs basicTypes/ NameEnv.lhs basicTypes/NameSet.lhs basicTypes/NewDemand.lhs basicTypes/ OccName.lhs basicTypes/RdrName.lhs basicTypes/SrcLoc.lhs basicTypes/ UniqSupply.lhs basicTypes/Unique.lhs basicTypes/Var.lhs basicTypes/ VarEnv.lhs basicTypes/VarSet.lhs cmm/CLabel.hs cmm/Cmm.hs cmm/ CmmBrokenBlock.hs cmm/CmmCPS.hs cmm/CmmCPSGen.hs cmm/CmmCallConv.hs cmm/CmmInfo.hs cmm/CmmLex.hs cmm/CmmLint.hs cmm/CmmLive.hs cmm/ CmmOpt.hs cmm/CmmParse.hs cmm/CmmProcPoint.hs cmm/CmmUtils.hs cmm/ Dataflow.hs cmm/MachOp.hs cmm/PprC.hs cmm/PprCmm.hs codeGen/Bitmap.hs codeGen/CgBindery.lhs codeGen/CgCallConv.hs codeGen/CgCase.lhs codeGen/ CgClosure.lhs codeGen/CgCon.lhs codeGen/CgExpr.lhs codeGen/ CgForeignCall.hs codeGen/CgHeapery.lhs codeGen/CgHpc.hs codeGen/ CgInfoTbls.hs codeGen/CgLetNoEscape.lhs codeGen/CgMonad.lhs codeGen/ CgParallel.hs codeGen/CgPrimOp.hs codeGen/CgProf.hs codeGen/ CgStackery.lhs codeGen/CgTailCall.lhs codeGen/CgTicky.hs codeGen/ CgUtils.hs codeGen/ClosureInfo.lhs codeGen/CodeGen.lhs codeGen/ SMRep.lhs coreSyn/CoreFVs.lhs coreSyn/CoreLint.lhs coreSyn/ CorePrep.lhs coreSyn/CoreSubst.lhs coreSyn/CoreSyn.lhs coreSyn/ CoreTidy.lhs coreSyn/CoreUnfold.lhs coreSyn/CoreUtils.lhs coreSyn/ ExternalCore.lhs coreSyn/MkExternalCore.lhs coreSyn/PprCore.lhs coreSyn/PprExternalCore.lhs cprAnalysis/CprAnalyse.lhs deSugar/ Check.lhs deSugar/Coverage.lhs deSugar/Desugar.lhs deSugar/ DsArrows.lhs deSugar/DsBinds.lhs deSugar/DsCCall.lhs deSugar/ DsExpr.lhs deSugar/DsForeign.lhs deSugar/DsGRHSs.lhs deSugar/ DsListComp.lhs deSugar/DsMeta.hs deSugar/DsMonad.lhs deSugar/ DsUtils.lhs deSugar/Match.lhs deSugar/MatchCon.lhs deSugar/ MatchLit.lhs ghci/ByteCodeAsm.lhs ghci/ByteCodeFFI.lhs ghci/ ByteCodeGen.lhs ghci/ByteCodeInstr.lhs ghci/ByteCodeItbls.lhs ghci/ ByteCodeLink.lhs ghci/Debugger.hs ghci/GhciMonad.hs ghci/GhciTags.hs ghci/InteractiveUI.hs ghci/Linker.lhs ghci/ObjLink.lhs ghci/ RtClosureInspect.hs hsSyn/Convert.lhs hsSyn/HsBinds.lhs hsSyn/ HsDecls.lhs hsSyn/HsDoc.hs hsSyn/HsExpr.lhs hsSyn/HsImpExp.lhs hsSyn/ HsLit.lhs hsSyn/HsPat.lhs hsSyn/HsSyn.lhs hsSyn/HsTypes.lhs hsSyn/ HsUtils.lhs iface/BinIface.hs iface/BuildTyCl.lhs iface/IfaceEnv.lhs iface/IfaceSyn.lhs iface/IfaceType.lhs iface/LoadIface.lhs iface/ MkIface.lhs iface/TcIface.lhs main/BreakArray.hs main/CmdLineParser.hs main/CodeOutput.lhs main/Config.hs main/Constants.lhs main/ DriverMkDepend.hs main/DriverPhases.hs main/DriverPipeline.hs main/ DynFlags.hs main/ErrUtils.lhs main/Finder.lhs main/GHC.hs main/ HeaderInfo.hs main/HscMain.lhs main/HscStats.lhs main/HscTypes.lhs main/InteractiveEval.hs main/Main.hs main/PackageConfig.hs main/ Packages.lhs main/ParsePkgConf.hs main/PprTyThing.hs main/ StaticFlags.hs main/SysTools.lhs main/TidyPgm.lhs nativeGen/ AsmCodeGen.lhs nativeGen/GraphBase.hs nativeGen/GraphColor.hs
Re: ANNOUNCE: GHC version 6.8.2
Hi Christophe,
On Dec 23, 2007, at 11:02 AM, alpheccar wrote:
Was someone able to build ghc 6.8.2 on PPC with OS X 10.4 (Tiger) ?
I had no problems to build the 6.8.1 but with 6.8.2, I get the error:
I was able to build 6.8.2 three times on PPC/Tiger (10.4.11) without
error
using 6.6.1 as a boostrap compiler. What are you using to compile
6.8.2?
../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 -hide-
all-packages -split-objs -i -idist/build/autogen -idist/build -i. -
Idist/build -Iinclude -#include HsBase.h -odir dist/build -hidir
dist/build -stubdir dist/build -package rts-1.0 -O -fglasgow-exts -
package-name base -XCPP -idist/build -H16m -O -O -Rghc-timing -
fgenerics -c Data/Generics/Twins.hs -o dist/build/Data/Generics/
Twins.o -ohi dist/build/Data/Generics/Twins.hi
ghc-6.8.2: panic! (the 'impossible' happened)
(GHC version 6.8.2 for powerpc-apple-darwin):
lookupVers1 base:GHC.Prim sym{tc}
Please report this as a GHC bug: http://www.haskell.org/ghc/
reportabug
Best Wishes,
Greg
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Re: ANNOUNCE: GHC version 6.8.2
Hi, On Dec 20, 2007, at 2:31 PM, Hugo Pacheco wrote: From the ghc-6.8.2 sources then, I'm just afraid of possible errors, and I don't have any previous ghc installed. Do the sources permit bootstrapping? From what I know... The source distribution needs an installed GHC (version 6.0 at least). If your platform isn't currently supported with a binary distribution, then you'll need to consult the section on Porting GHC in the Building Guide. I'm afraid of the same error as macports 6.6.1: configure: error: GHC is required unless bootstrapping from .hc files. The macports 6.8.2 should be ready soon for Tiger (PPC and Intel) and Leopard (Intel only). I have had successful builds on these platforms and the Portfile is updated. However, the 6.8 branch seems to have introduced a bug in file locking (#1992 in the trac) that causes the build to fail once out of every four or five times. This is not acceptable for a production release, so this has to be tracked down before GHC from macports is updated. Sorry for the delay, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Re: ANNOUNCE: GHC version 6.8.2
On Dec 20, 2007, at 5:30 PM, Hugo Pacheco wrote: But is it like days, weeks, months? I really need GHC installed on my intel mac w/ leopard. The new macports ghc should be ready in days to a week, most likely. If you want I can send you the portfile to try, I can't guarantee it but it seems to work most of the time. If the build fails, just sudo port clean and try again. How can I build the libraries in the current leopard release? I don't understand your question. Which libraries do you want to build? -Greg ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 on Mac OS 10.5 Leopard (Intel) - Configure fails
On Dec 10, 2007, at 3:21 PM, Carsten Keßler wrote: Basically, I just wanted to get this thing running without too much hassle... Does anyone have an idea why the GHC distribution available via MacPorts does not work at the moment? Hi Carsten, The ghc distribution on MacPorts doesn't support 6.8.1 yet because I haven't finished porting it. The whole 6.8.1 release is sort of a mess. Our old bootstrap compiler on ppc (version 6.4) seems not to be able to build 6.8.1, contrary to expectations. I can get 6.6.1 to build 6.8.1, so I may just have to update the bootstrap compiler. (Updating the bootstrap compiler is a fair amount of work, mostly to check that no unnecessary dependencies get included. This is essential so that the process just works for most people.) I had asked on this list several days ago if anyone knew what versions of ghc were capable of building 6.8.1 and received no answer to this question. AFAIK, only 6.6.1 is capable of building 6.8.1, despite the the website's advertising that any version 6.0 should be sufficient. (The libraries for 6.8.1 seem to need 6.2 or later.) This will all take some time to sort out but it is being worked on. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Which ghc versions can build ghc-6.8.1?
Hi,
I'm the process of updating MacPort's ghc to 6.8.1 and adding support
for
Leopard (OS X 10.5) and have been having] some trouble.
The first task is just to get 6.8.1 running on Tiger (10.4). On PPC,
I use
ghc 6.4 as a bootstrap compiler and on Intel ghc 6.6. I am traveling
with
only a PPC PowerBook G4/OS X 10.4, so that's all I've been able to
test with.
The problem is that ghc 6.4 can not build 6.8.1. It seems related to
Cabal.
Using the 6.4 bootstrap compiler (with the version of Cabal that it
shipped
with) I get:
ranlib libHSrts_thr_debug.a
== Finished recursively making `all' for ways: p debug thr thr_p
thr_debug ...
PWD = /opt/local/var/macports/build/_Users_gwright_src_macports-
trunk_dports_lang_ghc/work/ghc-6.8.1/rts
make -C libraries boot
rm -f -rf bootstrapping.Cabal
cp -R Cabal bootstrapping.Cabal
/usr/bin/find bootstrapping.Cabal \( -name *.o -o -name *.hi \) \
-exec rm -f -f {} \;
touch stamp/bootstrapping.Cabal
rm -f -rf bootstrapping.filepath
cp -R filepath bootstrapping.filepath
/usr/bin/find bootstrapping.filepath \( -name *.o -o -name *.hi \) \
-exec rm -f -f {} \;
touch stamp/bootstrapping.filepath
rm -f -rf ifBuildable
mkdir ifBuildable
cp ifBuildable.hs ifBuildable/
cd ifBuildable /opt/local/var/macports/build/
_Users_gwright_src_macports-trunk_dports_lang_ghc/work/ghc-bootstrap/
bin/ghc -Wall --make ifBuildable -o ifBuildable
Chasing modules from: ifBuildable
Compiling Main ( ifBuildable.hs, ifBuildable.o )
Linking ...
ld: warning prebinding disabled because dependent library: /opt/local/
lib/libgmp.3.dylib is not prebound
rm -f -rf base/setup
mkdir base/setup
cp base/Setup.*hs base/setup
cd base/setup /opt/local/var/macports/build/
_Users_gwright_src_macports-trunk_dports_lang_ghc/work/ghc-bootstrap/
bin/ghc -Wall -cpp --make Setup.*hs -o Setup \
-DCABAL_VERSION=1,2,2,0 -i../../
bootstrapping.Cabal -i../../bootstrapping.filepath
Chasing modules from: Setup.hs
Compiling System.FilePath.Posix ( ../../bootstrapping.filepath/System/
FilePath/Posix.hs, ../../bootstrapping.filepath/System/FilePath/
Posix.o )
Compiling System.FilePath ( ../../bootstrapping.filepath/System/
FilePath.hs, ../../bootstrapping.filepath/System/FilePath.o )
Compiling Main ( Setup.hs, Setup.o )
Setup.hs:19:18: Not in scope: `buildHook'
Setup.hs:21:30: Not in scope: `buildHook'
Setup.hs:22:18: Not in scope: `makefileHook'
Setup.hs:24:33: Not in scope: `makefileHook'
Setup.hs:25:18: Not in scope: `instHook'
Setup.hs:26:29: Not in scope: `instHook'
Setup.hs:33:12: Not in scope: `compilerFlavor'
Setup.hs:33:45: Not in scope: data constructor `GHC'
make[1]: *** [base/setup/Setup] Error 1
make: *** [stage1] Error 2
If I upgrade the bootstrap compiler's Cabal to 1.1.6.2, the build
still fails.
(The old version of Cabal was unregistered according the instructions
for working with older versions of ghc Cabal.)
ranlib libHSrts_thr_debug.a
== Finished recursively making `all' for ways: p debug thr thr_p
thr_debug ...
PWD = /Users/gwright/Desktop/ghc-6.8.1/rts
make -C libraries boot
rm -f -rf bootstrapping.Cabal
cp -R Cabal bootstrapping.Cabal
/usr/bin/find bootstrapping.Cabal \( -name *.o -o -name *.hi \) \
-exec rm -f -f {} \;
touch stamp/bootstrapping.Cabal
rm -f -rf bootstrapping.filepath
cp -R filepath bootstrapping.filepath
/usr/bin/find bootstrapping.filepath \( -name *.o -o -name *.hi \) \
-exec rm -f -f {} \;
touch stamp/bootstrapping.filepath
rm -f -rf ifBuildable
mkdir ifBuildable
cp ifBuildable.hs ifBuildable/
cd ifBuildable /opt/local/bin/ghc -Wall --make ifBuildable -o
ifBuildable
Chasing modules from: ifBuildable
Compiling Main ( ifBuildable.hs, ifBuildable.o )
Linking ...
rm -f -rf base/setup
mkdir base/setup
cp base/Setup.*hs base/setup
cd base/setup /opt/local/bin/ghc -Wall -cpp --make Setup.*hs -o
Setup \
-DCABAL_VERSION=1,2,2,0 -i../../
bootstrapping.Cabal -i../../bootstrapping.filepath
Chasing modules from: Setup.hs
Compiling System.FilePath.Posix ( ../../bootstrapping.filepath/System/
FilePath/Posix.hs, ../../bootstrapping.filepath/System/FilePath/
Posix.o )
Compiling System.FilePath ( ../../bootstrapping.filepath/System/
FilePath.hs, ../../bootstrapping.filepath/System/FilePath.o )
Compiling Main ( Setup.hs, Setup.o )
Setup.hs:22:18: Not in scope: `makefileHook'
Setup.hs:24:33: Not in scope: `makefileHook'
make[1]: *** [base/setup/Setup] Error 1
make: *** [stage1] Error 2
With my installed 6.6.1 (and the Cabal 1.1.6.2 shipped with it) I was
Re: 6.6.1 + DoCon on Mac OS
Hi Serge, On Sep 4, 2007, at 4:27 AM, Serge D. Mechveliani wrote: People, please, who can advise about ghc-6.6.1 + DoCon on Mac OS ? in DoCon-2.09 and tell whether this installation is likely to work under Mac OS ? How DoCon-2.09 + ghc-6.6.1 can be ported to Mac OS ? I ported DoCon 2.09 to OS X using the MacPorts infrastructure several months ago. It built fine, and I was able to run a few simple tests. I didn't check it in for some reason --- I probably just forgot. I have fixed that. DoCon is now available from MacPorts. The build depends on having ghc from MacPorts. If ghc is not installed, it will be built from source. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Failure building HEAD
Hi Ian, On Jun 8, 2007, at 11:24 AM, Ian Lynagh wrote: On Thu, Jun 07, 2007 at 11:56:35AM -0400, Gregory Wright wrote: Is this a problem with the HEAD branch or do I need a development version of cabal from the darcs repository to build the latest ghc? I'm not sure exactly what you mean. You need the latest darcs Cabal in libraries/Cabal in your GHC tree, and if this is a tree that you have previously built then you may also need to first remove libraries/stamp/bootstrapping.Cabal. However, you don't need the latest Cabal registered with the GHC that you are building /with/. I started by deleting my old directory and doing a fresh get from the darcs repository so there was nothing left over from a previous build. It looks as if something is broken then. For example, --configure-option=-O2 is showing up in the command line of gcc when one of the test programs is built by the configure script in libraries/base. I assume that this should just have been - O2. The configure script fails because gcc barfs on the unrecognized option. So no new dependencies have been introduced in the HEAD build as I understand it. Anyone else have problems building HEAD in the last couple of days. I know it's not just me; it was reported to me by another person using macports to build HEAD. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Failure building HEAD
Hi Ian, On Jun 8, 2007, at 12:03 PM, Ian Lynagh wrote: Hmm, what is the complete command (i.e. with all arguments) that starts cd base setup/Setup configure? make -C libraries all rm -f -f stamp/configure.library.*.base base/unbuildable ( cd base setup/Setup configure \ --enable-library-profiling --enable-split-objs \ --prefix=/opt/local/var/db/dports/build/ _Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/ destroot//opt/local \ --with-compiler=../../compiler/ghc-inplace \ --with-hc-pkg=../../utils/ghc-pkg/ghc-pkg-inplace \ --with-hsc2hs=../../utils/hsc2hs/hsc2hs-inplace \ --with-ld=/usr/bin/ld \ --datasubdir=ghc \ --haddock-args=--use-contents=../index.html \ --use-index=../doc-index.html \ --configure-option='--prefix=/opt/local' --configure- option='--prefix=/opt/local/var/db/dports/build/ _Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/ destroot//opt/local' --configure-option='--mandir=/opt/local/var/db/ dports/build/_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/ work/destroot//opt/local/share/man/' --configure-option='--with- readline-includes=/opt/local/include' --configure-option='--with- readline-libraries=/opt/local/lib' --configure-option='--with-gmp- includes=/opt/local/include' --configure-option='--with-gmp- libraries=/opt/local/lib' --configure-option='--disable-openal' -- configure-option='--disable-alut' --configure-option='CFLAGS=-I/opt/ local/include --configure-option=-O2' --configure-option='CPPFLAGS=-I/ opt/local/include --configure-option=-I/opt/local/include' -- configure-option='LDFLAGS=-L/opt/local/lib --configure-option=-L/opt/ local/lib' \ --configure-option=--with-cc=gcc ) \ touch stamp/configure.library.build-profiling- splitting.base || touch base/unbuildable Setup: Warning: Unknown field 'nhc98-options' configure: Reading installed packages... Configuring base-2.1... configure: Using install prefix: /opt/local/var/db/dports/build/ _Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ opt/local configure: Binaries installed in: /opt/local/var/db/dports/build/ _Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ opt/local/bin configure: Libraries installed in: /opt/local/var/db/dports/build/ _Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ opt/local/lib/base-2.1/ghc-6.7.20070608 configure: Private binaries installed in: /opt/local/var/db/dports/ build/_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/ destroot/opt/local/libexec configure: Data files installed in: /opt/local/var/db/dports/build/ _Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ opt/local/share/ghc configure: Using compiler: ../../compiler/ghc-inplace configure: Compiler flavor: GHC configure: Compiler version: 6.7.20070608 configure: Using package tool: ../../utils/ghc-pkg/ghc-pkg-inplace configure: Using ar found on system at: /usr/bin/ar configure: Using haddock found on system at: /opt/local/bin/haddock configure: Using ld given by user at: /usr/bin/ld configure: No pfesetup found configure: Using ranlib found on system at: /usr/bin/ranlib configure: Using runghc found on system at: /opt/local/bin/runghc configure: Using runhugs found on system at: /opt/local/bin/runhugs configure: Using tar found on system at: /usr/bin/tar configure: Using happy: /opt/local/bin/happy configure: Using alex: /opt/local/bin/alex configure: Using hsc2hs: ../../utils/hsc2hs/hsc2hs-inplace configure: Using c2hs: /opt/local/bin/c2hs configure: Using cpphs: /opt/local/bin/cpphs configure: No greencard found configure: Reading installed packages... Configuring base-2.1... configure: Dependency rts-any: using rts-1.0 configure: Using install prefix: /opt/local/var/db/dports/build/ _Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ opt/local configure: Binaries installed in: /opt/local/var/db/dports/build/ _Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ opt/local/bin configure: Libraries installed in: /opt/local/var/db/dports/build/ _Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ opt/local/lib/base-2.1/ghc-6.7.20070608 configure: Private binaries installed in: /opt/local/var/db/dports/ build/_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/ destroot/opt/local/libexec configure: Data files installed in: /opt/local/var/db/dports/build/ _Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ opt/local/share/ghc configure: Using compiler: ../../compiler/ghc-inplace configure: Compiler flavor: GHC configure: Compiler version: 6.7.20070608 configure: Using package tool: ../../utils/ghc-pkg/ghc-pkg-inplace checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create
Failure building HEAD
Hi, Today I was building HEAD using macports and had the error: configure: Using compiler: ../../compiler/ghc-inplace configure: Compiler flavor: GHC configure: Compiler version: 6.7.20070607 configure: Using package tool: ../../utils/ghc-pkg/ghc-pkg-inplace checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. (this was in libraries/base). The config.log showed the problem: configure:1680: checking for C compiler default output file name configure:1683: gcc -I/opt/local/include --configure-option=-O2 -I/ opt/local/include --configure-option=-I/opt/local/include -L/opt/ local/lib --configure-option=-L/opt/local/lib conftest.c 5 cc1: error: unrecognized command line option -fconfigure-option=-O2 cc1: error: unrecognized command line option -fconfigure-option=-I/ opt/local/includecc1: error: unrecognized command line option - fconfigure-option=-L/opt/local/libconfigure:1686: $? = 1 It looks like cabal is messed up, passing --configure-option= when it should be stripping it out. Is this a problem with the HEAD branch or do I need a development version of cabal from the darcs repository to build the latest ghc? Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.6.1 for FreeBSD/amd64 binary distribution
Hi, I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64 at http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown- freebsd.tar.bz2 No documentation or ghci. The former might be easily remedied although using FreeBSD's docbook chain, as suggested in the wiki, fails when asked to generate printable docs. The latter seems to be a bigger project since my naive interpretation of the problem is that we need data relocations across a 2GB boundary. The binary works well enough to build itself and darcs. There are only sixteen unexpected test suite failures thus far. I am ignoring these for the moment while I get back to thinking about ghci. Note that you need to install libgmp to use the compiler. libgmp from the ports collection works fine. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6.1 for FreeBSD/amd64 binary distribution
Hi Simon, On May 30, 2007, at 4:05 PM, Simon Marlow wrote: Gregory Wright wrote: I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64 at http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown- freebsd.tar.bz2 yay! Ian will supply a link from the download page in due course, I'm sure. I still owe you some source patches to make the compiler build out of the box. If 6.6.1 is the end of the line, would you prefer that these be against HEAD? Should I ask for push permission or just send these via the usual darcs send route (now possible, since darcs builds on x86_64)? The x86-64 (or amd64 if you like) Linux port doesn't do relocation of data references outside 2Gb. It is the subject of this bug: http://hackage.haskell.org/trac/ghc/ticket/781 the underlying problem is that the relocatable reference is only 32 bits, because we're working in the small memory model, but the address of the symbol might be outside the current 2Gb slice, because it's in a shared library somewhere. The system linker solves this by relocating the data itself from the shared library into the main program's 2Gb slice (I think), but we can't do this in GHCi. Hmm. I would have thought that the absolute addresses of static data in the shared library would have been resolved by the run time loader and written into the global offset table. It seems that all of the shared libraries on FreeBSD/amd64 are loaded at addresses above 2 GB, e.g., above 0x8. Perhaps rtld allocates space below 2GB and fills in adjusts the GOT to point to the data in lower memory. (There's not very much of it). I'll have to think about this a while. Fortunately most code doesn't reference static data from shared libraries, so we get away with it most of the time. FreeBSD/amd64 seems to make a lot of references to static data. When I edited the Linker to ignore out of range relocations and print a message I got dozens while starting GHCi. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Buildng ghc-devel from macports
Hi Ian, On Apr 13, 2007, at 9:19 AM, Ian Lynagh wrote: On Thu, Apr 12, 2007 at 11:07:03AM -0400, Gregory Wright wrote: configure: No cpphs found configure: No greencard found Setup: Unrecognised flags: --with-cc=gcc make[1]: *** [stamp/configure.library.build-profiling.base] Error 1 make: *** [stage1] Error 2 it to me directly (I maintain the macports ghc-devel port) if you'd like. It sounds like the port needs to be updated to run sh boot instead of autoreconf. I can do this, but the previous procedure worked until a couple of weeks ago. Has something changed? Greg ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Buildng ghc-devel from macports
Hi Ian, On Apr 13, 2007, at 11:56 AM, Ian Lynagh wrote: On Fri, Apr 13, 2007 at 10:27:54AM -0400, Gregory Wright wrote: I can do this, but the previous procedure worked until a couple of weeks ago. Has something changed? Yes; autoreconf and configure no longer recurse into the libraries (as cabal was running configure too, so it was being run twice unnecessarily). The ghc-devel port in macports now uses the boot script instead of autoreconf. This fixes the reported problem. It seems as if someone has some work in progress that breaks the build, but that's the risk when building from HEAD. Best Wishes, Greg ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Buildng ghc-devel from macports
Hi Chris, On Apr 12, 2007, at 9:48 AM, C.M.Brown wrote: Hello, I've been trying to build the ghc-devel package (6.7) from macports. However the build seems to fail half through. Specifically when running the setup for base-2.1: configure: Using compiler: ../../compiler/ghc-inplace configure: Compiler flavor: GHC configure: Compiler version: 6.7.20070411 configure: Using package tool: ../../utils/ghc-pkg/ghc-pkg-inplace configure: Using ar found on system at: /usr/bin/ar configure: Using haddock found on system at: /opt/local/bin/haddock configure: Using ld given by user at: /usr/bin/ld configure: No pfesetup found configure: Using ranlib found on system at: /usr/bin/ranlib configure: Using runghc found on system at: /opt/local/bin/runghc configure: No runhugs found configure: Using tar found on system at: /usr/bin/tar configure: Using happy: /opt/local/bin/happy configure: Using alex: /opt/local/bin/alex configure: Using hsc2hs: ../../utils/hsc2hs/hsc2hs-inplace configure: No c2hs found configure: No cpphs found configure: No greencard found Setup: Unrecognised flags: --with-cc=gcc make[1]: *** [stamp/configure.library.build-profiling.base] Error 1 make: *** [stage1] Error 2 Hope someone can help! kind regards, Chris. To tell what's going on I'll need the build.log output of sudo port -dv build ghc-devel build.log 21 This will be quite long, and you might want to compress it. You can send it to me directly (I maintain the macports ghc-devel port) if you'd like. Please remember to run sudo port clean ghc-devel first to clean out any previous stuff. Macports can not yet properly restart an interrupted build. Best Wishes, Greg ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Just a further note on the FreeBSD/amd64 port. I have the mangler fixed up now, so the only remaining issue is the linker. I hope to send patches soon. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Hi Olli, On Apr 10, 2007, at 1:23 PM, Oliver Braun wrote: Hi Gregory, * Gregory Wright [EMAIL PROTECTED] [2007-04-09 12:38 -0400]: I have ghc-6.6 (darcs version from 20070405) running registerized on FreeBSD/amd64. I will certainly provide patches and a binary distribution that people can use to bootstrap their own compilers. It would be nice if you cann provide a bootstrap tarball for integration in the FreeBSD lang/ghc port. I will do this as soon as I get the Linker bugs worked out so we can have ghci. Since this won't make it into 6.6.1 a few patches will have to be applied to the distribution. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Hi Ian, On Apr 9, 2007, at 12:21 PM, Ian Lynagh wrote: On Sun, Apr 08, 2007 at 07:49:24PM -0400, Gregory Wright wrote: I have ghc-6.6 (darcs version from 20070405) running registerized on FreeBSD/amd64. Excellent! Well done, and thanks for persevering! It would be great if you could let us have a bindist and any necessary patches. I will certainly provide patches and a binary distribution that people can use to bootstrap their own compilers. I will try to get ghci running before I put out a release. If you compile a module with ghc -v -keep-tmp-files then you should see the commandline it is using, and it should leave the files for you to examine, and rerun the commands on, afterwards. I'm giving this a try right now. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Hi Ian, On Apr 9, 2007, at 12:21 PM, Ian Lynagh wrote: With this patch, we are pretty close. However, there still seems to be something wrong with the splitter. I can make a working registerized compiler if I set splitObjs=NO in build.mk, but it seems as if whatever is wrong with ghc-split shouldn't be too hard to fix. I've glanced at ghc-split.lprl, but on what files is it invoked? Can I run it from the command line on a file and see check what comes out? If you compile a module with ghc -v -keep-tmp-files then you should see the commandline it is using, and it should leave the files for you to examine, and rerun the commands on, afterwards. I did this and immediately discovered that the problem is not with ghc-split but with ghc-asm. .globl directives are being deleted when they shouldn't be. This is somewhat reminiscent of bug #1167, except that it seems to happen far more frequently on amd64. Perhaps someone has an idea of the top of their head for this one. I wouldn't be surprised if the fix for this also took care of the bug on the less loved linux-ppc platform. Best Wishes. Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
FreeBSD/amd64 registerised running
Hi Ian, Simon,
I have ghc-6.6 (darcs version from 20070405) running registerized on
FreeBSD/amd64. The FreeBSD version is 6.2.
The problem with the compiler crash turned out to be simple. In the
FreeBSD header file regex.h, regex_t is defined as
typedef struct {
int re_magic;
size_t re_nsub; /* number of parenthesized
subexpressions */
__const char *re_endp; /* end pointer for REG_PEND */
struct re_guts *re_g; /* none of your business :-) */
} regex_t;
The problem is that the re_magic field is defined as an int. When
building
the .hc files on the i386 host, the re_nsub field is at an offset of
4. On the
amd64 target, it is at an offset of 8. In the ghc binding to the
regex functions,
re_nsub is used to compute how much memory to allocate in a call to
allocaBytes. This leads to garbage being passed to newPinnedByteArray#.
The fix is to patch libraries/base/Text/Regex/Posix.hs on the amd64
target:
--- libraries/base/Text/Regex/Posix.hs.sav Thu Apr 5 12:05:22 2007
+++ libraries/base/Text/Regex/Posix.hs Thu Apr 5 12:05:45 2007
@@ -106,7 +106,7 @@
regexec (Regex regex_fptr) str = do
withCString str $ \cstr - do
withForeignPtr regex_fptr $ \regex_ptr - do
- nsub - ((\hsc_ptr - peekByteOff hsc_ptr 4)) regex_ptr
+ nsub - ((\hsc_ptr - peekByteOff hsc_ptr 8)) regex_ptr
{-# LINE 109 Posix.hsc #-}
let nsub_int = fromIntegral (nsub :: CSize)
allocaBytes ((1 + nsub_int) * (16)) $ \p_match - do
With this patch, we are pretty close. However, there still seems to be
something wrong with the splitter. I can make a working registerized
compiler if I set splitObjs=NO in build.mk, but it seems as if
whatever is
wrong with ghc-split shouldn't be too hard to fix.
The splitting problem shows up as a linking failure. Some variables
defined in the text section are changed from global symbols to local
symbols by the splitter. An example (just one of several hundred
symbols that are changed from global to local):
From building ghc-6.6-20070405 on i386:
nm --defined-only libHSbase.a | grep D
snip
D base_TextziReadziLex_zdLr3bklvl122_closure
and from building ghc-6.6-20070405 on amd64:
nm --defined-only libHSbase.a | grep d
snip
d base_TextziReadziLex_zdLr3bklvl122_closure
The D on i386 indicates a global symbol, the d on amd64
a local symbol.
I've glanced at ghc-split.lprl, but on what files is it invoked? Can
I run it from the command line on a file and see check what comes out?
The file itself doesn't say what it expects as input, and the section
of the Commentary on the splitter is more than terse.
The linker is still broken (so no ghci):
greenhouse-george ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6.20770405, for
Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
ghc-6.6.20770405: internal error: R_X86_64_PC32 relocation out of
range: __isthreaded = 0xfff800122aad
(GHC version 6.6.20070405 for x86_64_unknown_freebsd)
Please report this as a GHC bug: http://www.haskell.org/ghc/
reportabug
Abort trap: 6 (core dumped)
but I think I understand this. On FreeBSD mmap does not have the
MAP_32BIT option that linux does to guarantee a mapping in first
2 GB of address space. But by supplying a hint address in the lower
address space we can get the effect the MAP_32BIT option. I thought I
had this fixed in the patch I applied to Linker.c, but I have
obviously overlooked
something.
I'm continuing to work on the linker, and expect that it will be working
soon. I'd appreciate a some guidance on the splitter question as I am
entirely unfamiliar with it.
Best Wishes,
Greg
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: More on FreeBSD/amd64
Hi Ian, On Apr 1, 2007, at 6:22 PM, Ian Lynagh wrote: On Sun, Apr 01, 2007 at 06:10:25PM -0400, Gregory Wright wrote: Ah, remove the #if/#endif around the definition of puts, its export, and the GHC.Pack import in libraries/base/GHC/Handle.hs No such luck. I even copied puts into libraries/base/GHC/ ForeignPtr.hs but I still get I cycle because I need withCString to define puts: Oh, the 6.4.2 definition is different to the 6.6 definition. Does the 6.6 one work with 6.4.2?: puts :: String - IO () puts s = do write_rawBuffer 1 (unsafeCoerce# (packCString# s)) 0 (fromIntegral (length s)) return () (packCString# come from GHC.Pack) Still doesn't work. If I include the definition of write_rawBuffer just above puts (I can't import GHC.Handle because of the dependency loop) and dangerously change CInt to Int in the signature (can't import Foreign.C.Types for the same reason) I still get an error message saying that fromInteger is out of scope. This is what I have added to libraries/base/GHC/ForeignPtr.hs: import GHC.List ( null ) import GHC.Base import GHC.IOBase import GHC.List ( length ) import GHC.Pack -- this is new import GHC.Ptr ( Ptr(..) ) import GHC.Err import GHC.Show foreign import ccall unsafe __hscore_PrelHandle_write write_rawBuffer :: Int - RawBuffer - Int - Int - IO Int puts :: String - IO () puts s = do write_rawBuffer 1 (unsafeCoerce# (packCString# s)) 0 (length s) return () I'm wondering if I should just give up on trying to print anything out from this deep in the libraries and go back to looking at the debugger trace. My guess is still that a FreeBSD libc function is getting called and somehow storing a 32 bit value in a 64 bit location, with junk in the high order word. As always, hints and firm whacks on the side of the head will be appreciated. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc development version (6.7) from MacPorts
Hi, For those who live on the bleeding edge, I have made a port of the latest development version of ghc for OS X through MacPorts. (If you are not familiar with MacPorts, see http://macports.org.) The build is from the darcs repository, and installs its binaries as bin_name-6.7.date_code . This naming allows the development version to be installed alongside the released ghc-6.6 with no conflicts. The port should work with OS X 10.3 and later on Intel or PPC. The name of the port is ghc-devel. Note that because this is really a _development_ version, it may be buggy or not build at all. For day to day use you want the released ghc-6.6. Have fun, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] ghc-6.7.20070330 on Mac OS X
Hi Ruben, The GHC wiki also has information on this, and should be your first stop if you are experiencing build problems: http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX At least under MacPorts, I have had no trouble building 6.7-20070330. I will be releasing a new portfile for ghc-devel in a few days that will build the latest from the darcs repository. Best Wishes, Greg On Apr 1, 2007, at 11:50 AM, Pepe Iborra wrote: (redirecting to glasgow-haskell-users) It is well known that the readline lib that comes with OS X is no good, and you need to use a replacement. A nice post from the blogosphere explaining all this: http://mult.ifario.us/articles/2006/10/17/ghc-6-6-and-mac-os-x- readline-quick-fix If that doesn't help, please post the errors that you get when building the readline package. Cheers pepe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: More on FreeBSD/amd64
Hi Ian, On Apr 1, 2007, at 3:57 PM, Ian Lynagh wrote: Hi Gregory, Is there a version of print I can use for debugging these libraries? Just adding print causes a cycle in module dependencies. Ah, remove the #if/#endif around the definition of puts, its export, and the GHC.Pack import in libraries/base/GHC/Handle.hs No such luck. I even copied puts into libraries/base/GHC/ ForeignPtr.hs but I still get I cycle because I need withCString to define puts: Module imports form a cycle for modules: GHC.ForeignPtr imports: GHC.Show GHC.Err GHC.Ptr GHC.IOBase GHC.Base GHC.List Foreign.Storable Foreign.Ptr Foreign.C Control.Monad Foreign.C imports: Foreign.C.Error Foreign.C.String Foreign.C.Types Foreign.C.Error imports: GHC.Base GHC.Num GHC.IOBase Data.Maybe Foreign.Marshal.Error Foreign.C.String Foreign.C.Types Foreign.Ptr Foreign.Storable GHC.IOBase Foreign.C.String imports: GHC.Base GHC.IOBase GHC.Num GHC.Real GHC.List Data.Word Foreign.Storable Foreign.Ptr Foreign.C.Types Foreign.Marshal.Array Foreign.C.Types Data.Typeable imports: GHC.Arr GHC.Stable GHC.ForeignPtr GHC.Ptr GHC.STRef GHC.ST GHC.IOBase GHC.IOBase GHC.Real GHC.Float GHC.Num GHC.Err GHC.Show GHC.Base Data.List Data.Word Data.Int Data.Either Data.Maybe Data.HashTable Foreign.Marshal.Array imports: GHC.Base GHC.Err GHC.List GHC.Num GHC.IOBase Foreign.Marshal.Utils Foreign.Marshal.Alloc Foreign.Storable Foreign.Ptr Control.Monad Foreign.Marshal.Utils imports: GHC.Base GHC.Num GHC.Real GHC.IOBase Foreign.Marshal.Alloc Foreign.C.Types Foreign.Storable Foreign.Ptr Data.Maybe Foreign.Marshal.Alloc imports: GHC.Num GHC.Base GHC.Err GHC.Ptr GHC.Real GHC.IOBase Foreign.ForeignPtr Foreign.Storable Foreign.C.Types Foreign.Ptr Data.Maybe Foreign.ForeignPtr imports: GHC.ForeignPtr GHC.Err GHC.Num GHC.IOBase GHC.Base Foreign.Storable Foreign.Ptr ghc: 150783504 bytes, 23 GCs, 1498056/2873752 avg/max bytes residency (3 samples), 19M in use, 0.00 INIT (0.00 elapsed), 0.48 MUT (1.76 elapsed), 0.06 GC (0.07 elapsed) :ghc gmake[1]: *** [depend] Error 1 gmake: *** [boot] Error 1 gmake: Leaving directory `/tmp/ghc-6.4.2/libraries' GHC.ForeignPtr does seem to be the root of much evil, since everything seems to depend on it. Any other hints on how I could get some output? BTW, I have done some more tracing with gdb and I think I am a bit closer to the underlying bug. Before the bad call to newPinnedByteArray#, there are a number of calls to functions bound to libc's regex functions (e.g., regcomp, regexec). Since this is FreeBSD's libc, there may easily be differences from the much better tested glibc. It looks like the regex functions are being used to look up package names, since I thought I saw a call from somewhere in Cabal.Distribution. I need to check this once I get ghc-6.4.2 rebuilt. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: More on FreeBSD/amd64
Hi SImon, On Mar 29, 2007, at 5:40 AM, Simon Marlow wrote: Hi Greg, Good analysis so far. I think you're close to this one. Thank you for checking over what I've done thus far. Based on what you said, I looked at Compat.Unicode and there is indeed a type error in this foreign call: foreign import ccall unsafe u_gencat wgencat :: CInt - Int The return type should be CInt, not Int. Try changing that and see if it helps. You might need to add some fromIntegrals. I noticed this too yesterday and tried correcting it this morning. Changing the return type from Int to CInt didn't help. The problem will no doubt be subtle, yet entirely obvious in retrospect. I'll try to get some time to work on it in the next few days. It's still a bit puzzling why this problem affects FreeBSD, and apparently not Linux. Differences in header files? Cheers, Simon Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
More on FreeBSD/amd64
Hi Ian, I have made some more progress on understanding the build failure on FreeBSD/amd64. I could use a check on my understanding of the problem, though. The setup: I have an unregisterized ghc-6.4.2 successfully built on FreeBSD/amd64. It was bootstrapped from .hc files compiled on FreeBSD/i386. I am attempting to use this compiler (the ghc-inplace from the unregisterized build, not a fully installed compiler) to build a recent ghc-6.6 branch from darcs (20070314). The build of ghc-6.6-20070314 fails when compiling rts/Linker.c. The failure is mostly reproducible (more about that below). It's also worth remembering that when I tried to build an unregisterized ghc-6.6 on FreeBSD/amd64 using .hc files from ghc-6.6 built on FreeBSD/i386, I had a crash at the same place, while trying to build rts/Linker.c The failure comes from trying to allocate a huge amount of memory. newPinnedByteArrayzh_fast is called with a giant argument, 0x400010. So it looks like we're after 16 bytes, but the upper 32 bits has some junk in it. The above was the state of things just over a week ago. Since then, I've worked to track down whether the bug is in the ghc-6.4.2 runtime or in the ghc-6.6 code. The compiler that fails is the 6.6 stage1 compiler, which is a 6.6 compiler linked with the runtime from the unregisterized 6.4.2 (let me know if I'm wrong about that). I have rebuilt the unregisterized 6.4.2 with optimization turned off. I haven't got any more information this way; it seems the problem is really on the 6.6 side. Here is my reasoning: I run the 6.6 compiler under the debugger: greenhouse-george gdb /tmp/ghc/compiler/stage1/ghc-6.6.20070314 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... (gdb) dir /tmp/ghc-6.4.2/ghc/rts Source directories searched: /tmp/ghc-6.4.2/ghc/rts:$cdir:$cwd (gdb) b newPinnedByteArrayzh_fast Breakpoint 1 at 0x163cbb4 (gdb) run -B/tmp/ghc -v -optc-O -optc-Wall -optc-W -optc-Wstrict- prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations - optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc- I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc- fomit-frame-pointer -optc-I/usr/local/include -optc-fno-strict- aliasing -H16m -O -optc-O2 -static -I/usr/local/include -I. -#include HCIncludes.h -fvia-C -dcmm-lint -c Linker.c -o Linker.o Starting program: /tmp/ghc/compiler/stage1/ghc-6.6.20070314 -B/tmp/ ghc -v -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc- Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc- Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc- I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer - optc-I/usr/local/include -optc-fno-strict-aliasing -H16m -O -optc-O2 - static -I/usr/local/include -I. -#include HCIncludes.h -fvia-C -dcmm- lint -c Linker.c -o Linker.o Breakpoint 1, 0x0163cbb4 in newPinnedByteArrayzh_fast () By playing around with it, I have isolated --- more or less --- when the failure occurs. In this run, it was after 973 calls to newPinnedByteArrayzh_fast. If I quit gdb and re-run it, the number of calls is consistently the same. However, from one system boot to the next, it varies a bit. Yesterday morning, I had to skip 976 calls. (gdb) c 973 Will ignore next 972 crossings of breakpoint 1. Continuing. Glasgow Haskell Compiler, Version 6.6.20070314, for Haskell 98, compiled by GHC version 6.4.2 Using package config file: /tmp/ghc/driver/package.conf.inplace wired-in package base not found. wired-in package rts mapped to rts-1.0 wired-in package haskell98 not found. wired-in package template-haskell not found. Hsc static flags: -static -static Created temporary directory: /tmp/ghc1073_0 *** C Compiler: gcc -x c Linker.c -o /tmp/ghc1073_0/ghc1073_0.s -v -S -Wimplicit -O - D__GLASGOW_HASKELL__=606 -O -Wall -W -Wstrict-prototypes -Wmissing- prototypes -Wmissing-declarations -Winline -Waggregate-return -Wbad- function-cast -I../includes -I. -Iparallel -DCOMPILING_RTS -fomit- frame-pointer -I/usr/local/include -fno-strict-aliasing -O2 -I /usr/ local/include -I . -I /tmp/ghc/includes -fwrapv Breakpoint 1, 0x0163cbb4 in newPinnedByteArrayzh_fast () OK, I should be at the call which is going to blow up: (gdb) bt #0 0x0163cbb4 in newPinnedByteArrayzh_fast () #1 0x016377ea in StgRun (f=0x163cbb0 newPinnedByteArrayzh_fast, basereg=0x260fcd0) at StgCRun.c:93 #2 0x01631f48 in schedule (mainThread=0x2611080, initialCapability=0x0) at Schedule.c:932 #3 0x01633190 in waitThread_ (m=0x2611080,
Progress building unregisterised for FreeBSD/amd64
Hi Ian, I have made some progress. Today I got 6.4.2 to build unregisterized on my FreeBSD/amd64 box. I went back to 6.4.2 because the only actual report of success I could find record of was Wilhelm Kloke's. He used 6.4.1. I made certain I had exactly the same versions of readline and gmp on both machines. This might not be necessary, but it's one less thing that might go wrong. I also downgraded my ghc to 6.4.2 on the host i386 system. Building 6.4.2 using 6.6 runs into trouble with the change in the mutable array API. The 6.4.2 build now runs successfully to the end of the hc-build script. I haven't installed it, but tried to build an out of the box 6.6 with the 6.4.2 ghc-inplace. (I applied my patch to Linker.c so that the build wouldn't fail merely because of undefined symbols.) I also patched the mangler by adding |freebsd to rules for /^x86_64-.*-(linux|openbsd)$/. The interesting thing is that out of the box using the 6.4.2 bootstrap compiler, 6.6 still crashes when compiling Linker.c. Not just a little crash; it hung the whole system. At that point it is using the ghc-inplace of 6.6. On Mar 13, 2007, at 3:05 PM, Ian Lynagh wrote: This sounds like you are using the original 6.6? You're probably better off trying to start from the 6.6 darcs branch instead (make a tarball of a checkout (might as well run autoreconf first) so you can be sure you have the same source on both machines). As I said, I'm using out of the box 6.6. Should I try a 6.6 from darcs? ../compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict- prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations - optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc- I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc- fomit-frame-pointer -optc-fno-strict-aliasing -H16m -O -optc-O2 - static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -c Linker.c - o Linker.o Segmentation fault (core dumped) gmake: *** [Linker.o] Error 139 gmake: Leaving directory `/tmp/ghc-6.6/rts' ../compiler/ghc-inplace has successfully compiled other files by this point, right? Yes. I've built the 6.6 compiler with the 6.4.2 bootstrap, and the inplace 6.6 has built everything up until Linker.c. Then crash, burn, smoking ruin. It probably won't help, but what does it say if you add -v? I suspect the next step is to try gdb and see what it says, though. It might be necessary to repeat the build with -g -O0 in GhcHcOpts or other variables (be wary of hc-build trampling changes you make to mk/build.mk). It might even be useful to tweak the process so that you end up with a -debug ghc (in fact, this should probably be the default). I don't have instructions for how to do this, but I've done it in the past and don't remember any major difficulties. Basically stick SRC_HC_OPTS += - debug in compiler/Makefile and fix any problems that come up (you might need to do things like make WAY=debug in rts/, and modify the list of files that get put in the tarball). I can add -v. Should I try to build a vanilla 6.6 with debugging or one out of darcs? Which would be more useful? Thanks for your help. Thanks Ian Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Building unregisterised for FreeBSD/amd64
Hi, I'm trying to get ghc-6.6 running on my FreeBSD/amd64 box. It seems as if the build instructions are stale again. When I run $ cd /tmp/ghc-6.6/rts gmake boot gmake it falls over in the RTS, as noted in the documentation. But at the next step, when the libraries are built, $ cd ../libraries $ gmake boot gmake cabal fails to build because it requires HSrts. This aborts the library build leaving me with an incomplete set of libraries. Is there a simple way to tell the build not to make cabal? Best, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building unregisterised for FreeBSD/amd64
Hi Christian, On Mar 2, 2007, at 11:40 AM, Christian Maeder wrote: Gregory Wright schrieb: cabal fails to build because it requires HSrts. This aborts the library build leaving me with an incomplete set of libraries. Is there a simple way to tell the build not to make cabal? I think you can simply delete Cabal from: SUBDIRS = ... of libraries/Makefile HTH Christian Deleting Cabal from SUBDIRS=... in libraries/Makefile fixes one probelm, but then the build fails because of a later dependency on Cabal when doing $ cd ../compiler $ gmake boot stage=2 gmake stage=2 Removing the Cabal dependency from compiler/Makefile and the associated package.conf.* files doesn't help because compiler/main/CodeOutput.lhs depends on Distribution.Package for showPackageId. Is the best course just to give up on 6.6 and go back to 6.4.2, then use 6.4.2 to bring up 6.6? It seems odd that Cabal is so deeply intertwined with the compiler that you can't build the compiler without it. Does anyone know if this is intentional or unavoidable, or did incremental hacking just get us here by accident? Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem running X11 on PPC Mac
Hi Christian, On Nov 15, 2006, at 9:14 AM, Christian Maeder wrote: Gregory Wright schrieb: /opt/local/lib/ghc-6.6/HSX11_cbits.o: unknown symbol `_printf $LDBLStub' I think I remember seeing something like this. I'll look into it some more. That's a gcc problem. I think, HSX11_cbits.o should be built with gcc-3.3. (I assume your default is gcc-4.0.) Try adding -pgmc /usr/bin/gcc-3.3 to ghc's command-line. It may be possible to keep gcc 4.0 and just link in -lSystemStubs. That were the undefined symbol lives. Christian P.S. I had to set DYLIB_LIBRARY_PATH, before it worked for me Yes, it looks like I'll have to patch up the ghc script some more find find X11 properly. Greg ___ 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: Problem running X11 on PPC Mac
Brad, Did you apply the recent X11 update from Apple after you compiled ghc? If so, you might try uninstalling, cleaning and rebuilding the macports ghc. There is a path issue; you should not have to specify DYLIB_LIBRARY_PATH. At least in macports, this should be easy to fix. Greg On Nov 12, 2006, at 9:08 AM, Brad wrote: Hi, I have the same problem both with the binary distribution and ghc compiled from macports/ darwinports, but only with ghci. If I compile things, it appears that things are linked properly. Has anyone found a solution for this, or does anyone have an idea of what I could try? Should this be reported as a bug? Launching ghci from an xterm window, I get $ ghci -package X11-1.1 ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package X11-1.1 ... ghc-6.6: can't load .so/.DLL for: X11 (dlopen(libX11.dylib, 10): image not found) I ran a ktrace to see where it was looking for the library, and got ... 381 ghc-6.6 CALL stat(0x1b057d8,0x1b05770) 381 ghc-6.6 NAMI /opt/local/lib/ghc-6.6/libX11_dyn.dylib 381 ghc-6.6 RET stat -1 errno 2 No such file or directory 381 ghc-6.6 CALL stat(0x1b05888,0x1b05820) 381 ghc-6.6 NAMI /opt/local/lib/ghc-6.6/libX11.dylib 381 ghc-6.6 RET stat -1 errno 2 No such file or directory 381 ghc-6.6 CALL open(0x1b058b8,0,0) 381 ghc-6.6 NAMI libX11.dylib 381 ghc-6.6 RET open -1 errno 2 No such file or directory 381 ghc-6.6 CALL close(0x) 381 ghc-6.6 RET close -1 errno 9 Bad file descriptor 381 ghc-6.6 CALL open(0xbfffd150,0,0) 381 ghc-6.6 NAMI /Users/username/lib/libX11.dylib 381 ghc-6.6 RET open -1 errno 2 No such file or directory 381 ghc-6.6 CALL close(0x) 381 ghc-6.6 RET close -1 errno 9 Bad file descriptor 381 ghc-6.6 CALL open(0xbfffd150,0,0) 381 ghc-6.6 NAMI /usr/local/lib/libX11.dylib 381 ghc-6.6 RET open -1 errno 2 No such file or directory 381 ghc-6.6 CALL close(0x) 381 ghc-6.6 RET close -1 errno 9 Bad file descriptor 381 ghc-6.6 CALL open(0xbfffd160,0,0) 381 ghc-6.6 NAMI /usr/lib/libX11.dylib 381 ghc-6.6 RET open -1 errno 2 No such file or directory 381 ghc-6.6 CALL close(0x) 381 ghc-6.6 RET close -1 errno 9 Bad file descriptor ... So it is not looking in /usr/X11R6/lib. I tried the same thing with DYLD_LIBRARY_PATH=/usr/X11R6/lib and get $ DYLD_LIBRARY_PATH=/usr/X11R6/lib ghci -package X11-1.1 ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. ghc-6.6: /opt/local/lib/ghc-6.6/HSX11_cbits.o: unknown symbol `_printf $LDBLStub' Loading package X11-1.1 ... linking ... ghc-6.6: unable to load package `X11-1.1' What's the problem? Thanks. Brad ___ 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: Problem running X11 on PPC Mac
Hi Brad, On Nov 13, 2006, at 7:22 AM, Brad wrote: On 13/11/06, Gregory Wright [EMAIL PROTECTED] wrote: Brad, Did you apply the recent X11 update from Apple after you compiled ghc? I did. If so, you might try uninstalling, cleaning and rebuilding the macports ghc. I did try that, and got: $ DYLD_LIBRARY_PATH=/usr/X11R6/lib ghci -package X11-1.1 ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. ghc-6.6: /opt/local/lib/ghc-6.6/HSX11_cbits.o: unknown symbol `_printf $LDBLStub' Loading package X11-1.1 ... linking ... ghc-6.6: unable to load package `X11-1.1 ' I think I remember seeing something like this. I'll look into it some more. This is after I uninstalled, removed the package, and recompiled ghc, yesterday (that is to say, after I updated the Apple X11): $ ls -lT /opt/local/bin/ghc lrwxr-xr-x 1 root admin 7 Nov 12 18:36:50 2006 /opt/local/bin/ ghc - ghc-6.6 $ ls -lT /opt/local/var/db/dports/packages/darwin/powerpc/ghc-6.6_1 +darwin_8_powerpc.powerpc.tgz -rw-r--r-- 1 root admin 59818580 Nov 12 18:36:14 2006 /opt/local/var/db/dports/packages/darwin/powerpc/ghc-6.6_1 +darwin_8_powerpc.powerpc.tgz Why does the Apple X11 always have to break things? There is a path issue; you should not have to specify DYLIB_LIBRARY_PATH. At least in macports, this should be easy to fix. I guess so - I had a look at the portfile and it seems that the syntax is straightforward enough, but I have no experience fiddling with that. But that's a separate issue, right? I already tweak the script that invokes ghc/ghci to find the libraries installed by macports. Tweaking it a bit more is not a big deal. But I would like to understand the unknown symbol problem first. Best, Greg Any other ideas? In any case, thanks for your help. ___ 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: GHC 6.6 for OS X using MacPorts
Hi Aaron, On Oct 27, 2006, at 12:42 PM, Aaron Tomb wrote: Hello, The Portfile has made it to the servers, but installation doesn't complete successfully for me (on Intel/10.4.8). The first issue is that something happens to the dynamic library lookup path so the configure check for a working C compiler fails with a dyld error. I managed to fix this with the following: cd /usr mkdir i686-apple-darwin8 cd i686-apple-darwin8 ln -s ../lib This allows configure to complete, but then it seems to have trouble finding the bootstrap compiler. I've attached the entire output, since I think context is important. If it seems more appropriate for this discussion to continue on the MacPorts mailing list, let me know. Can you tell me which version of Xcode you are running? Do open /Developer/Applications/Xcode.app then under the Xcode menu look at About Xcode . It should give the version number, as well as the component version number. Send those to me. Everything seems to work fine for some installation on Intel, and others have seen the problem you describe. Look very much like some Xcode version issue. Best WIshes, Greg Aaron ghc-macports.log On Oct 27, 2006, at 6:59 AM, Gregory Wright wrote: Hi, GHC 6.6 is now available for OS X systems on both Intel and PowerPC processors using the MacPorts infrastructure. The compiler is built from source, using a binary bootstrap compiler. OS X versions 10.3 (Panther) and 10.4 (Tiger) are supported for PowerPC processors; for Intel processors, version 10.4. MacPorts (formerly Darwinports) is a packaging system for managing builds of unix-compatible software on OS X. For more information on MacPorts, see http://www.macports.org/ A new ghc-devel port will soon be available for those who just have to live on the bleeding edge. Best Wishes, Greg Gregory Wright Antiope Associates LLC [EMAIL PROTECTED] ___ 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6 for OS X using MacPorts
Aaron, On Oct 27, 2006, at 12:42 PM, Aaron Tomb wrote: Hello, The Portfile has made it to the servers, but installation doesn't complete successfully for me (on Intel/10.4.8). The first issue is that something happens to the dynamic library lookup path so the configure check for a working C compiler fails with a dyld error. I managed to fix this with the following: cd /usr mkdir i686-apple-darwin8 cd i686-apple-darwin8 ln -s ../lib This allows configure to complete, but then it seems to have trouble finding the bootstrap compiler. I've attached the entire output, since I think context is important. If it seems more appropriate for this discussion to continue on the MacPorts mailing list, let me know. One more thing: After adding the symlink, you must do sudo port clean ghc to clean up the failed build before trying again. Macports is not smart enough to do that yet, but if you don't, you will have all kinds of unpredictable problems. -Greg Aaron ghc-macports.log On Oct 27, 2006, at 6:59 AM, Gregory Wright wrote: Hi, GHC 6.6 is now available for OS X systems on both Intel and PowerPC processors using the MacPorts infrastructure. The compiler is built from source, using a binary bootstrap compiler. OS X versions 10.3 (Panther) and 10.4 (Tiger) are supported for PowerPC processors; for Intel processors, version 10.4. MacPorts (formerly Darwinports) is a packaging system for managing builds of unix-compatible software on OS X. For more information on MacPorts, see http://www.macports.org/ A new ghc-devel port will soon be available for those who just have to live on the bleeding edge. Best Wishes, Greg Gregory Wright Antiope Associates LLC [EMAIL PROTECTED] ___ 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: OpenGL failing with Mac Intel 6.6 distribution
On Oct 28, 2006, at 1:41 PM, Deborah Goldsmith wrote: On Oct 28, 2006, at 10:14 AM, Gregory Wright wrote: My guess is that your compiler was built without OpenGL support. If you downloaded a binary compiler, you're stuck until someone adds it. Look at the output of ghc-pkg list Do you see GLUT-* andfOpenGL-* ? If not, you do not have OpenGL support. $ ghc-pkg list /usr/local/lib/ghc-6.6/package.conf: Cabal-1.1.6, GLUT-2.0, HGL-3.1, HUnit-1.1, OpenGL-2.1, QuickCheck-1.0, X11-1.1, base-2.0, cgi-2006.9.6, fgl-5.2, (ghc-6.6), haskell-src-1.0, haskell98-1.0, html-1.0, mtl-1.0, network-2.0, parsec-2.0, readline-1.0, regex-base-0.71, regex-compat-0.71, regex-posix-0.71, rts-1.0, stm-2.0, template-haskell-2.0, time-1.0, unix-1.0, xhtml-2006.9.13 Since it failed at the gcc stage rather than the ghc stage, I don't think that it's that the package wasn't installed. I think something about the way the distribution was put together is wrong. If you built your ghc from source, make sure you have enabled hopengl that the opengl libraries are found (save the build logs and look in the configuration sections). This is the binary Intel build that is listed on the GHC 6.6 downloads page. It looks like something is wrong with that build. I guess I'll try building it from source instead. If you build from source make sure you have Xcode 2.4 (the latest). I'm getting reports of build problems on OS X/Intel, which seem to all be related to older versions of Xcode. Greg Deborah ___ 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
GHC 6.6 for OS X using MacPorts
Hi, GHC 6.6 is now available for OS X systems on both Intel and PowerPC processors using the MacPorts infrastructure. The compiler is built from source, using a binary bootstrap compiler. OS X versions 10.3 (Panther) and 10.4 (Tiger) are supported for PowerPC processors; for Intel processors, version 10.4. MacPorts (formerly Darwinports) is a packaging system for managing builds of unix-compatible software on OS X. For more information on MacPorts, see http://www.macports.org/ A new ghc-devel port will soon be available for those who just have to live on the bleeding edge. Best Wishes, Greg Gregory Wright Antiope Associates LLC [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6 for OS X using MacPorts
On Oct 27, 2006, at 10:25 AM, C.M.Brown wrote: Hi Greg, I have just been trying to install ghc 6.6 using Darwin Ports, but the search facility can't find ghc-6.6. : sudo port selfupdate DarwinPorts base version 1.320 installed Downloaded MacPorts base version 1.320 The MacPorts installation is not outdated and so was not updated selfupdate done! dhcp2940:~ cmb21$ port search ghc ghclang/ghc 6.4.2The Glorious Glasgow Haskell Compilation System ghc-devel lang/ghc-devel 6.5 The Glorious Glasgow Haskell Compilation System (development version) dhcp2940:~ cmb21$ Am I doing something wrong? No, just give the servers a few hours to run their update scripts. Then the new portfiles will be available by selfupdate. (I confess I do not know how often these days the scripts run, but it is at least a couple of times per day, IIRC.) If by, say, UTC 28 Oct 2006 you don't see the new portfiles, let me know. Something might be wacky with the server. Sorry for the delay. Best Wishes, Greg Kind regards, Chris Brown, On Fri, 27 Oct 2006, Gregory Wright wrote: Hi, GHC 6.6 is now available for OS X systems on both Intel and PowerPC processors using the MacPorts infrastructure. The compiler is built from source, using a binary bootstrap compiler. OS X versions 10.3 (Panther) and 10.4 (Tiger) are supported for PowerPC processors; for Intel processors, version 10.4. MacPorts (formerly Darwinports) is a packaging system for managing builds of unix-compatible software on OS X. For more information on MacPorts, see http://www.macports.org/ A new ghc-devel port will soon be available for those who just have to live on the bleeding edge. Best Wishes, Greg Gregory Wright Antiope Associates LLC [EMAIL PROTECTED] ___ 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.6 Release Candidate
Hi Simon, Which version of the testsuite should I be using to test my builds of the release candidates? Best Wishes, Greg On Sep 1, 2006, at 6:03 AM, Simon Marlow wrote: Only a week late, we are pleased to announce the Release Candidate phase for GHC 6.6. Snapshots beginning with 6.5.20060831 are release candidates for 6.6 Download snapshots from here: http://www.haskell.org/ghc/dist/current/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060831- src.tar.bz2 http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060831-src- extralibs.tar.bz2 Only the first of these is necessary. The extralibs package contains various extra packages that we normally supply with GHC (and a couple of new ones) - unpack the extralibs tarball on top of the source tree to add them, they will be included in the build automatically. There are also currently binary distributions for x86_64/Linux (Fedora Core 5), i386/Linux (RedHat 7(!)), and Windows. More may appear later. Please test as much as possible, bugs are much cheaper if we find them before the release! Which brings me on to the release itself: we had planned to release before ICFP, but that only leaves just over a week, which isn't really enough time to test the RC thoroughly, so it's looking like the 6.6 release will happen after ICFP now. In the meantime we have the RC to play with, so enjoy... Cheers, Simon ___ 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: [GHC] #729 Build system uses wrong version of include files.
Shaun,Could you run sudo port clean ghc sudo port -dv install ghc install.log 21and send the install.log file? The "-dv" flag supply verbosedebugging output. Running clean first shouldclean out any junk left over from a failed build. (You shouldalways run it if for some reason a build failed or was interruptedbefore trying again.)Best Wishes,GregOn Sep 1, 2006, at 9:09 AM, Simon Marlow wrote: Shaun Lippy reports that #729 is happening for him too (I previously closed this bug assuming driver error). Can someone on MacOS X reproduce and possibly diagnose this please? Cheers, Simon From: Shaun Lippy [mailto:[EMAIL PROTECTED]] Sent: 30 August 2006 05:22To: [EMAIL PROTECTED]Subject: Re: [GHC] #729 Build system uses wrong version of include files. Hi Simon -I am seeing this error as well, building for Tiger. I simply ran 'sudo port install ghc'. This proceeded to go get the GMP libs, built them successfully; it then gets the Perl that it needs, successfully builds that; it gets something called Readline, successfully builds that. Then it gets GHC and starts to build that; it is in stage 1 build. Here's the entire output of the sudo command mentioned:adsl-64-109-253-64:~ slippy$ sudo port install ghcPassword:--- Fetching gmp--- Attempting to fetch gmp-4.2.1.tar.bz2 from ftp://ftp.gnu.org/gnu/gmp--- Verifying checksum(s) for gmp--- Extracting gmp--- Configuring gmp--- Building gmp with target all--- Staging gmp into destrootrunning ranlib on static libraries --- Installing gmp 4.2.1_4+test--- Activating gmp 4.2.1_4+test--- Cleaning gmp--- Fetching perl5.8--- Attempting to fetch perl-5.8.8.tar.bz2 from http://www.cpan.org/src/5.0/--- Verifying checksum(s) for perl5.8--- Extracting perl5.8--- Applying patches to perl5.8--- Configuring perl5.8--- Building perl5.8 with target all --- Staging perl5.8 into destroot--- Installing perl5.8 5.8.8_0+darwin_8--- Activating perl5.8 5.8.8_0+darwin_8--- Cleaning perl5.8--- Fetching readline--- Attempting to fetch readline51-001 from ftp://ftp.cwru.edu/pub/bash/readline-5.1-patches/--- Attempting to fetch readline51-002 from ftp://ftp.cwru.edu/pub/bash/readline-5.1-patches/--- Attempting to fetch readline51-003 from ftp://ftp.cwru.edu/pub/bash/readline-5.1-patches/--- Attempting to fetch readline51-004 from ftp://ftp.cwru.edu/pub/bash/readline-5.1-patches/--- Attempting to fetch readline-5.1.tar.gz from ftp://ftp.gnu.org/gnu/readline--- Verifying checksum(s) for readline--- Extracting readline--- Applying patches to readline--- Configuring readline--- Building readline with target all --- Staging readline into destroot--- Installing readline 5.1.004_0--- Activating readline 5.1.004_0--- Cleaning readline--- Fetching ghc--- Attempting to fetch ghc-6.4.2-src.tar.bz2 from http://www.haskell.org/ghc//dist/6.4.2/--- Attempting to fetch happy-1.15-src.tar.gz from http://www.haskell.org/happy/dist/1.15 --- Attempting to fetch ghc-6.4-darwin-bootstrap-tiger.tar.bz2 from http://www.haskell.org/ghc//dist/6.4/MacOSX/--- Verifying checksum(s) for ghc --- Extracting ghc--- Applying patches to ghc--- Configuring ghc--- Building ghc with target allError: Target com.apple.build returned: shell command "DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib make all" returned error 2 Command output: /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/compMan -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include " hschooks.h"' -i../lib/compat -ignore-package Cabal -c basicTypes/OccName.lhs-boot -o stage1/basicTypes/OccName.o-boot -ohi stage1/basicTypes/OccName.hi-bootghc: 28500036 bytes, 8 GCs, 2406298/4716080 avg/max bytes residency (2 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.14 MUT (0.27 elapsed), 0.14 GC (0.21 elapsed) :ghc/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn
Re: 6.4.3 and threaded RTS problems
I'll run the latest on my G4 tonight and we can see. Best Wishes, Greg On Aug 28, 2006, at 12:05 AM, David Kirkman wrote: I ran the testsuite against the current HEAD (as of saturday afternoon) and had far fewer failures. Is the last week's work supposed to have fixed so many test cases? Or are different machines giving different results? The tests that resulted in unexpected failures for greg were all run on my machine, but many of them worked on my setup. -david k. -- Results for a lightly loaded dual proc G5 running OS 10.4.7. OVERALL SUMMARY for test run started at Sat Aug 26 19:00:07 PDT 2006 1434 total tests, which gave rise to 6334 test cases, of which 0 caused framework failures 1107 were skipped 5138 expected passes 47 expected failures 3 unexpected passes 39 unexpected failures Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm,profasm) Unexpected failures: TH_repPatSig(normal) barton-mangler-bug(opt) conc019(opt) conc024(normal) conc039(threaded1) conc056(threaded1) ffi009(ghci) ffi016(normal,prof) gadt7(normal) galois_raytrace(opt,prof) maessen_hashtab(normal,opt,optasm,prof,profasm,ghci,threaded1) rnfail026(normal) signals002(ghci) tcfail068(normal) tcfail071(normal) tcfail090(normal) tcfail099(normal) tcfail103(normal) tcfail115(normal) tcfail140(normal) tcrun021(normal,opt,optasm,prof,profasm,ghci,threaded1) utf8_002(normal) utf8_003(normal) utf8_004(normal) utf8_005(normal) On 8/24/06, Gregory Wright [EMAIL PROTECTED] wrote: Here's what happened (this is after I applied David Kirkman's SMP.h patch to my tree). When I said 132 failures I was speaking from memory. The actual number was 136, as noted in the log: OVERALL SUMMARY for test run started at Mon Aug 14 11:20:03 EDT 2006 1412 total tests, which gave rise to 4711 test cases, of which 0 caused framework failures 658 were skipped 3882 expected passes 32 expected failures 3 unexpected passes 136 unexpected failures Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm) ds052(normal) Unexpected failures: TH_spliceE5_prof(normal) arr004(normal,opt,optasm) arr007(opt,optasm) barton-mangler-bug(opt,threaded2) cabal01(normal) cabal02(normal) cg016(normal,opt,optasm) cg051(opt,optasm) conc012(normal) conc014(opt,optasm) conc021(opt,optasm) conc024(normal,opt,optasm) conc034(normal,opt,optasm) conc037(threaded2) conc039(threaded1) conc052(opt) conc056(threaded1,threaded2) concprog001(normal,opt,optasm) concprog002(threaded2) dsrun005(opt,optasm) dsrun007(opt,optasm) dsrun008(opt,optasm) enum01(normal,opt,optasm) enum02(normal,opt,optasm) enum03(normal,opt,optasm) exceptions001(normal,opt,optasm) exceptions002(opt,optasm) forkprocess01(ghci) galois_raytrace(opt,threaded2) ghci013(ghci) ghcpkg04(normal) joao-circular(optasm) list001(normal,opt,optasm) maessen_hashtab(normal,opt,optasm,ghci,threaded1,threaded2) mod1(normal) mod150(normal) mod151(normal) mod152(normal) mod153(normal) mod2(normal) net001(normal,opt,optasm,ghci,threaded1,threaded2) net002(normal,opt,optasm,ghci,threaded1,threaded2) newtype(opt) pkg02_b(normal,opt,optasm) read003(normal) rw(normal) seward-space-leak(ghci) signals002(ghci) simpl011(normal,opt,optasm) strun002(opt) tc102(normal,opt,optasm) tc134(normal,opt,optasm) tc136(normal,opt,optasm) tc141(normal,opt,optasm) tcfail068(normal) tcfail071(normal) tcfail082(normal) tcfail090(normal) tcfail099(normal) tcfail103(normal) tcfail115(normal) tcfail140(normal) tcrun021(normal,opt,optasm,ghci,threaded1,threaded2) uri001(normal,opt,optasm,ghci,threaded1,threaded2) utf8_002(normal) utf8_003(normal) utf8_004(normal) utf8_005(normal) Cheers, Simon /Greg ___ 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.3 and threaded RTS problems
Hi Simon, On Aug 24, 2006, at 3:56 AM, Simon Marlow wrote: Hi Folks, Roman Leshchinskiy and I looked into the 6.4.3 crashes on Sparc/ Solaris yesterday. I think we may have found the problem, and it seems likely that this is the same problem affecting 6.4.3 on MacOS X. The threaded RTS is assuming in a couple of places that pthread_cond_wait() doesn't spuriously wake up, which is apparently the case on Linux but not true in general. I don't think this bug affects 6.6. I could be wrong, however. Does anyone on MacOS X have a recent testsuite run with the HEAD? I'll try to put together a fix for 6.4.3 when the 6.6 release cycle has died down. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users I built HEAD and ran ghc-regress last week. It looks like the compiler crashes are almost all gone. There are still 132 unexpected failures, but only one compiler crash. There are quite a number of RTS system crashes, but I do get tracebacks. I haven't looked at all of the crashes, but a number of them fail as conc052 does below, in RaiseAsync.c . ** Host Name: gregory-wrights-powerbook-g4-17 Date/Time: 2006-08-14 12:09:02.560 -0400 OS Version: 10.4.7 (Build 8J135) Report Version: 4 Command: conc052 Path:./conc052 Parent: sh [1344] Version: ??? (???) PID:1345 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xfffc Thread 0 Crashed: 0 conc052 0x00217020 raiseAsync + 496 (RaiseAsync.c:924) 1 conc052 0x0020fe3c scheduleDoGC + 204 (Schedule.c:2038) 2 conc052 0x00211390 scheduleWaitThread + 2032 (Schedule.c:704) 3 conc052 0x001feb20 main + 48 (Main.c:106) 4 conc052 0x1ab4 _start + 340 (crt.c:272) 5 conc052 0x195c start + 60 Thread 0 crashed with PPC Thread State 64: srr0: 0x00217020 srr1: 0xf030vrsave: 0x cr: 0x22002244 xer: 0x0004 lr: 0x00216fb4 ctr: 0x r0: 0x0015d044 r1: 0xb6c0 r2: 0x0025 r3: 0x015d7094 r4: 0x0006 r5: 0x0002 r6: 0x0001 r7: 0x r8: 0xfff8 r9: 0x r10: 0x002e r11: 0x0156c014 r12: 0x900016c0 r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x00204978 r21: 0x r22: 0x0001 r23: 0x0026a000 r24: 0x r25: 0x015794a0 r26: 0x015d7094 r27: 0x01579100 r28: 0x0003 r29: 0x0002 r30: 0x015794ac r31: 0x015794ac Binary Images Description: 0x1000 - 0x241fff conc052 /Users/gwright/src/haskell/ghc/ testsuite/tests/ghc-regress/concurrent/should_run/conc052 0x8fe0 - 0x8fe52fff dyld 45.3 /usr/lib/dyld 0x9000 - 0x901bbfff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x90213000 - 0x90218fff libmathCommon.A.dylib /usr/lib/system/ libmathCommon.A.dylib I can probably do a bit of testing in the next few weeks, but am on a deadline for getting some chip design work done. Alas, I am having to spend more time debugging my haskell simulation, which constantly blows stack, than fixing the circuit itself :-( Best, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.3 and threaded RTS problems
Hi Simon, On Aug 24, 2006, at 7:34 AM, Simon Marlow wrote: Gregory Wright wrote: I built HEAD and ran ghc-regress last week. It looks like the compiler crashes are almost all gone. There are still 132 unexpected failures, but only one compiler crash. Are these crashes all for the threaded2 way? We'll probably need to disable SMP on PPC for the 6.6 release, because I'm fairly sure it doesn't work (the workarounds we need for the weaker memory ordering on PPC aren't implemented). Ian is planning to sort this out before the release. Here's what happened (this is after I applied David Kirkman's SMP.h patch to my tree). When I said 132 failures I was speaking from memory. The actual number was 136, as noted in the log: OVERALL SUMMARY for test run started at Mon Aug 14 11:20:03 EDT 2006 1412 total tests, which gave rise to 4711 test cases, of which 0 caused framework failures 658 were skipped 3882 expected passes 32 expected failures 3 unexpected passes 136 unexpected failures Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm) ds052(normal) Unexpected failures: TH_spliceE5_prof(normal) arr004(normal,opt,optasm) arr007(opt,optasm) barton-mangler-bug(opt,threaded2) cabal01(normal) cabal02(normal) cg016(normal,opt,optasm) cg051(opt,optasm) conc012(normal) conc014(opt,optasm) conc021(opt,optasm) conc024(normal,opt,optasm) conc034(normal,opt,optasm) conc037(threaded2) conc039(threaded1) conc052(opt) conc056(threaded1,threaded2) concprog001(normal,opt,optasm) concprog002(threaded2) dsrun005(opt,optasm) dsrun007(opt,optasm) dsrun008(opt,optasm) enum01(normal,opt,optasm) enum02(normal,opt,optasm) enum03(normal,opt,optasm) exceptions001(normal,opt,optasm) exceptions002(opt,optasm) forkprocess01(ghci) galois_raytrace(opt,threaded2) ghci013(ghci) ghcpkg04(normal) joao-circular(optasm) list001(normal,opt,optasm) maessen_hashtab(normal,opt,optasm,ghci,threaded1,threaded2) mod1(normal) mod150(normal) mod151(normal) mod152(normal) mod153(normal) mod2(normal) net001(normal,opt,optasm,ghci,threaded1,threaded2) net002(normal,opt,optasm,ghci,threaded1,threaded2) newtype(opt) pkg02_b(normal,opt,optasm) read003(normal) rw(normal) seward-space-leak(ghci) signals002(ghci) simpl011(normal,opt,optasm) strun002(opt) tc102(normal,opt,optasm) tc134(normal,opt,optasm) tc136(normal,opt,optasm) tc141(normal,opt,optasm) tcfail068(normal) tcfail071(normal) tcfail082(normal) tcfail090(normal) tcfail099(normal) tcfail103(normal) tcfail115(normal) tcfail140(normal) tcrun021(normal,opt,optasm,ghci,threaded1,threaded2) uri001(normal,opt,optasm,ghci,threaded1,threaded2) utf8_002(normal) utf8_003(normal) utf8_004(normal) utf8_005(normal) Cheers, Simon /Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.3 and threaded RTS problems
Hi Simon, On Aug 24, 2006, at 7:34 AM, Simon Marlow wrote: Gregory Wright wrote: I built HEAD and ran ghc-regress last week. It looks like the compiler crashes are almost all gone. There are still 132 unexpected failures, but only one compiler crash. Are these crashes all for the threaded2 way? We'll probably need to disable SMP on PPC for the 6.6 release, because I'm fairly sure it doesn't work (the workarounds we need for the weaker memory ordering on PPC aren't implemented). Ian is planning to sort this out before the release. Cheers, Simon For the record, here are the crashes (not test failures) from build of HEAD on OS X ppc. I will sort through them to find out how many distinct failures there seem to be. Fortunately, the all knowing haskell-cafe list has explained my laziness to me and thereby fixed my stack overflow woes. Henceforth I promise to be, if not diligent and hardworking, at least strict :-) And thanks to them I should be able to find a few moments to look at the crash logs. Best, greg gregory-wrights-powerbook-g4-17 cat crashes Aug 14 11:23:42 gregory-wrights-powerbook-g4-17 crashdump[18790]: arr007 crashed Aug 14 11:23:42 gregory-wrights-powerbook-g4-17 crashdump[18790]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ arr007.crash.log Aug 14 11:23:53 gregory-wrights-powerbook-g4-17 crashdump[18806]: arr007 crashed Aug 14 11:23:53 gregory-wrights-powerbook-g4-17 crashdump[18806]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ arr007.crash.log Aug 14 11:38:30 gregory-wrights-powerbook-g4-17 crashdump[22522]: cg016 crashed Aug 14 11:38:30 gregory-wrights-powerbook-g4-17 crashdump[22522]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ cg016.crash.log Aug 14 11:50:37 gregory-wrights-powerbook-g4-17 crashdump[25697]: concprog001 crashed Aug 14 11:50:37 gregory-wrights-powerbook-g4-17 crashdump[25697]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ concprog001.crash.log Aug 14 11:51:34 gregory-wrights-powerbook-g4-17 crashdump[25773]: concprog001 crashed Aug 14 11:51:34 gregory-wrights-powerbook-g4-17 crashdump[25773]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ concprog001.crash.log Aug 14 12:00:32 gregory-wrights-powerbook-g4-17 crashdump[27844]: conc012 crashed Aug 14 12:00:32 gregory-wrights-powerbook-g4-17 crashdump[27844]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ conc012.crash.log Aug 14 12:03:59 gregory-wrights-powerbook-g4-17 crashdump[29119]: conc024 crashed Aug 14 12:03:59 gregory-wrights-powerbook-g4-17 crashdump[29119]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ conc024.crash.log Aug 14 12:05:30 gregory-wrights-powerbook-g4-17 crashdump[29822]: conc034 crashed Aug 14 12:05:30 gregory-wrights-powerbook-g4-17 crashdump[29822]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ conc034.crash.log Aug 14 12:05:34 gregory-wrights-powerbook-g4-17 crashdump[29842]: conc034 crashed Aug 14 12:05:34 gregory-wrights-powerbook-g4-17 crashdump[29842]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ conc034.crash.log Aug 14 12:05:37 gregory-wrights-powerbook-g4-17 crashdump[29858]: conc034 crashed Aug 14 12:05:37 gregory-wrights-powerbook-g4-17 crashdump[29858]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ conc034.crash.log Aug 14 12:09:03 gregory-wrights-powerbook-g4-17 crashdump[1346]: conc052 crashed Aug 14 12:09:03 gregory-wrights-powerbook-g4-17 crashdump[1346]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ conc052.crash.log Aug 14 12:16:48 gregory-wrights-powerbook-g4-17 crashdump[4545]: dsrun005 crashed Aug 14 12:16:48 gregory-wrights-powerbook-g4-17 crashdump[4545]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ dsrun005.crash.log Aug 14 12:16:50 gregory-wrights-powerbook-g4-17 crashdump[4561]: dsrun005 crashed Aug 14 12:16:50 gregory-wrights-powerbook-g4-17 crashdump[4561]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ dsrun005.crash.log Aug 14 12:17:10 gregory-wrights-powerbook-g4-17 crashdump[4723]: dsrun007 crashed Aug 14 12:17:10 gregory-wrights-powerbook-g4-17 crashdump[4723]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ dsrun007.crash.log Aug 14 12:17:12 gregory-wrights-powerbook-g4-17 crashdump[4739]: dsrun007 crashed Aug 14 12:17:12 gregory-wrights-powerbook-g4-17 crashdump[4739]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ dsrun007.crash.log Aug 14 12:17:22 gregory-wrights-powerbook-g4-17 crashdump[4814]: dsrun008 crashed Aug 14 12:17:22 gregory-wrights-powerbook-g4-17 crashdump[4814]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ dsrun008.crash.log Aug 14 12:17:24 gregory-wrights-powerbook-g4-17
Re: GHC 6.4.3 is stalled
Hi Simon, I'll set up ssh access to a dual processor FreeBSD box. It should be ready by later today (I'll send a note). Best, Greg On Aug 4, 2006, at 8:08 AM, Simon Marlow wrote: I just realised I sent the following only to [EMAIL PROTECTED], not glasgow-hasell-users: Simon Marlow wrote: Just a quick note to say thanks for all the offers of help on 6.4.3 - it's very encouraging to see so many people willing to offer their time and machines. The state of play so far: On FreeBSD, reports suggest that there's are one or possibly two problems exposed by the threaded RTS. The timeout program in the testsuite sometimes hangs, and GHC itself may hang when linked against the threaded RTS. This looks like a tricky one, so I'm going to try to look into it myself. I've installed FreeBSD 6.1 on an old laptop and I'm currently building 6.4.2 on it. On MacOS X / PPC, we have a crashing stage2 when linked against the threaded RTS. Gregory Wright is trying to reproduce the problem on a smaller scale (with something other than GHC). The timeout hanging problem apparently happens on MacOS X/Intel too (according to Joel Reymont). If I find the cause on FreeBSD, we can test the fix on MacOS X/Intel. I have an update on FreeBSD. I built the CVS 6.4 branch on a fresh install of FreeBSD, and ran the testsuite: OVERALL SUMMARY for test run started at Thu 3 Aug 2006 09:42:30 BST 1365 total tests, which gave rise to 4157 test cases, of which 0 caused framework failures 583 were skipped 3505 expected passes 46 expected failures 2 unexpected passes 21 unexpected failures Unexpected passes: cholewo-eval(optasm) ffi009(optasm) Unexpected failures: arith011(opt) barton-mangler-bug(normal,opt,ghci,threaded) cabal01(normal) galois_raytrace(ghci) ioref001(normal,threaded) joao-circular(normal,opt,optasm,threaded) newtype(opt) queryfdoption01(normal,opt,optasm,threaded) rn.prog006(normal) seward-space-leak(ghci) signals002(threaded) Some of those failures are probably due to running out of memory on this laptop (which only has 128M + 256M swap, I should have given it more swap). But I don't see any evidence of hanging timeout processes and stage2 apparently works fine. That means the problem only shows up on a dual proc/dual core (Gregory reported seeing this on a dual proc build of FreeBSD). Greg - can you give me SSH access to your box, and I'll take a look? Cheers, Simon ___ 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 on Mac OSX PPC
Hi, This is probably the libedit issue. On OS X, NetBSD's libedit is installed. Libedit provides a partial implementation of the readline API. On OS X, Apple has symlinked /usr/lib/libreadline.dylib to libedit. This is not a good idea. I submitted at patch to fix this and I think it was committed to HEAD. It detects that libedit is not libreadline and refuses to use it. It's not a problem on darwinports because I explicitly require that DP's readline be used and set up the path to find it during configuration. Best Wishes, Greg On Aug 1, 2006, at 11:25 AM, Simon Marlow wrote: Joel Reymont wrote: I give up! Mac PPC doesn't like me now that I'm on Intel. This is PPC, btw, and I _do_ have readline installed. GHC from DarwinPorts compiles just fine. [snip] /usr/bin/ld: Undefined symbols: _rl_initialize _rl_reset_terminal _add_history _readline collect2: ld returned 1 exit status Sorry, I don't have much to offer here. It looks like you're picking up a bogus readline library somehow. I do vaguely recall readline shenanigans being required on MacOS X, you might want to search the archives. Cheers, Simon ___ 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 on Mac OSX PPC
Hi Joel, On Jul 28, 2006, at 7:50 AM, Joel Reymont wrote: On Jul 28, 2006, at 11:42 AM, Simon Marlow wrote: You shouldn't have to run configure again, but make clean definitely. I still get the same allocateExec error. I'm still not sure how updating configure.ac in ghc and making clean was going to help :-). Perhaps trying a bigger stick is in order: make distclean autoreconf ./configure make make install If your configure.ac is changed, you will need to run autoreconf to get the new configure script. The distclean target to make should clean out the old configuration. -- http://wagerlabs.com/ ___ 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: Re[2]: GHC 6.4.3 is stalled
On Jul 28, 2006, at 6:28 AM, Bulat Ziganshin wrote: Hello Gregory, Thursday, July 27, 2006, 11:06:41 PM, you wrote: 3. Did the threaded RTS work on 6.4.1? Was it used by default? on 6.4.1 threaded RTS was used only in specially build libs. in debugging versions of libs and GHCi single-threaded RTS was used. developers of threaded programs was complaining about this situation because it makes their debugging much harder. so, in 6.4.2 ghci (and ghc) and debugging libraries was changed to use threaded RTS Yes. obvious workaround is to continue to build GHC and debugging libs with non-threaded RTS on the platforms where multi-threaded RTS is not reliable yet That is what we do for darwinports at the moment, and it is also the approach taken by FreeBSD. The question at the moment is how do we fix the threading bugs, so that these platforms work as specified. Having half of the supported platforms not work is not a solution in the long run. Best Wishes, Greg -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ 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: GHC 6.4.3 is stalled
Dear Simon, Some data and a few questions: 1. The failure on FreeBSD is not the same as on OS X. I built 6.4.2 from cvs on FreeBSD 6.1, and ran the ghc-regress tests. The tests took a long time to run (about 14 hours on a dual Xeon 2.8 GHz with 2 GB of memory). Towards the end of the tests, there were about 30 timeout processes running, apparently doing nothing but consuming cpu cycles. However, there were only 47 expected failures, about what I had expected. This is quite different from the situation on OS X, where 6.4.2 with the threaded RTS generates about 400 unexpected failures and about two dozen compiler crashes logged by CrashReporter. This is slightly unfortunate, since it means that the underlying bug is probably not the same on the two operating systems. 2. Notes on reproducing the FreeBSD 6.4.2 build: I used fpconfig from the ghc-6-4 branch; ghc, libraries, hslibs and testsuite from the ghc-6-4-2 branch; gnu make 3.80; autoconf 2.59. Gnu make 3.81 went into an infinite loop, much as gnu make 3.79 did when building ghc on OS X. 3. Did the threaded RTS work on 6.4.1? Was it used by default? It would be very helpful to know. I have built ghc 6.4.2 with debugging turned on using the instructions in the commentary, but haven't gotten a useful traceback after a crash. I can provide an RTS thread listing (+RTS -Ds) if that would be a starting point. Someone would have to explain what it means to me, though. 4. When running with debugging turned on, I have seen the assertion failure ghc-6.4.2: internal error: ASSERTION FAILED: file GC.c, line 4356 Please report this as a compiler bug. See: http://www.haskell.org/ghc/reportabug This points toward the stack being corrupted. Maybe a thread overflowing its stack? I'm not sure. The assertion that fails is ASSERT(frame bottom); It looks as if something has messed up the stack before this. I am willing to dig into this, but I need a bit more help with where to start. Best Wishes, Greg On Jul 25, 2006, at 6:50 AM, Simon Peyton-Jones wrote: Folks GHC 6.4.2's threaded runtime system does not work right on Solaris MacOSX Possibly FreeBSD We'd love to fix these bugs and release 6.4.3, but we are stalled because we don't have easy access to these platforms, nor do we have detailed expertise in their intimate details (which is where the bugs will be lurking). If you care about these platforms, would you like to lend a hand? We probably need more help than simply here's access to the platform, but we'd give you very strong support if you were willing to look into it. Failing that, I think we'll have to stick with 6.4.2. (And the same bugs may well show up in GHC 6.6, which we hope to release before ICFP.) Simon ___ 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 on Mac OSX PPC
Hi Joel, The -threaded flag is set in ghc/compiler/Makefile. Look around line 398, for SRC_HC_OPTS += -threaded -Greg On Jul 26, 2006, at 9:17 AM, Joel Reymont wrote: On Jul 26, 2006, at 2:06 PM, Gregory Wright wrote: The crash while building the crypto library was one of the first signs that the threaded RTS had a problem. My question was whether the CVS version has the flag set. I looked through mk/config.mk but could not figure it out quickly so I just set off another build of ghc. Should be ready in a few hours :-). I compiled crypto with ghc 6.5 on Mac Intel and it went through fine after some tweaks to cabal dependencies. -- http://wagerlabs.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MacOS X / PowerPC
Hi Simon, On Jul 7, 2006, at 4:26 AM, Simon Marlow wrote: Gregory Wright wrote: I followed the instruction in DebuggingGhcCrashes, and the instructions in the ghc commentary for building an rts with debugging and symbols. (Please let me know if there are any mistakes in these instructions that you know of!) The crash seems to always happen eventually, but I do not have a simple case that reproduces it quickly. Gdb's traceback doesn't give anything immediately useful, so I assume that the crash is in haskell code, not in C. The not-always-reproducible nature of the bug suggests deferencing a pointer into uninitialized memory. Both 6.4.2 and HEAD show the problem on OS X. It can be avoided by disabling the threaded rts, but that is not acceptable solution. This is a good datapoint, because it probably rules out much of the threaded RTS code in the RTS itself, which has changed significantly between 6.4.x and HEAD. A quick question: does the darcs repository have go back to 6.4.1? (The place to start looking a diff of the RTS from 6.4.1, which worked, and 6.4.2 or HEAD, which doesn't). If I am to take a few deep breaths and dive back into the problem, which branch should I use, 6.4.x or HEAD? No preference, since it's probably the same bug in both. Use whatever's easiest for you. I'll work with HEAD. Best Wishes, Greg Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MacOS X / PowerPC
Hi Simon, I followed the instruction in DebuggingGhcCrashes, and the instructions in the ghc commentary for building an rts with debugging and symbols. (Please let me know if there are any mistakes in these instructions that you know of!) The crash seems to always happen eventually, but I do not have a simple case that reproduces it quickly. Gdb's traceback doesn't give anything immediately useful, so I assume that the crash is in haskell code, not in C. The not-always-reproducible nature of the bug suggests deferencing a pointer into uninitialized memory. Both 6.4.2 and HEAD show the problem on OS X. It can be avoided by disabling the threaded rts, but that is not acceptable solution. If I am to take a few deep breaths and dive back into the problem, which branch should I use, 6.4.x or HEAD? Best Wishes, Greg On Jul 6, 2006, at 8:13 AM, Simon Marlow wrote: Gregory Wright wrote: I submitted a patch for ticket #766 this afternoon. Thanks, now comitted and merged. I've banged my head on ticket #751, building with debugging symbols and running under gdb, but have yet to get any useful information that would pin down the bug. Does http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes help at all? Cheers, Simon ___ 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: MacOS X / PowerPC
Simon, I submitted a patch for ticket #766 this afternoon. I've banged my head on ticket #751, building with debugging symbols and running under gdb, but have yet to get any useful information that would pin down the bug. Best, Greg On Jul 5, 2006, at 10:47 AM, Simon Marlow wrote: Hi Folks, As you may know, support on MacOS X/PowerPC hardware has been lacking a bit recently: there are outstanding showstoppers with 6.4.2. Our Mac hero Wolfgang Thaller has been busy, and hasn't had time to look into the problems or package 6.4.2 for MacOS X (at least I assume he's busy, that's the last I heard, but he didn't respond to my latest ping). So the mantle of powerpc-apple-darwin maintainer is probably up for grabs. 6.4.3 is held up because of this (but not just because of this). Can anyone help out? Relevant bugs: http://hackage.haskell.org/trac/ghc/ticket/751 http://hackage.haskell.org/trac/ghc/ticket/766 and Wolfgang, if you're listening, we miss you :-) Cheers, Simon ___ 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
ghc 6.4.1 for OS X from darwinports
Hi, GHC 6.4.1 is now available for OS X via the darwinports system. The compiler is built from source, using a binary bootstrap compilier. Both 10.3 (Panther) and 10.4 (TIger) are supported. For more information on darwinports, see: http://darwinports.opendarwin.org Best Wishes, Greg Gregory Wright Antiope Associates LLC [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.1 release candidate testing on OS X
On Aug 8, 2005, at 4:33 AM, Simon Marlow wrote:On 05 August 2005 23:05, Gregory Wright wrote: ghc-6.4.1.20050804 builds successfully on Mac OS X 10.4.2 using gcc3.3. This snapshot also appears to fix bug 1249527, "runhaskell causes GHCto segfault on OS X".The new compiler was also tested by building darcs-1.0.3.The build was done under the darwinports infrastructure using ghc-6.4as the bootstrapcompiler.I haven't yet tried to build using gcc 4.0; should I expect that towork yet? It might - we've been testing with gcc 4.0, but I believe the MacOS Xversion has some differences.Cheers, Simonghc-6.4.1.20050806 builds successfully on OS X 10.4.2 using Apple's gcc-4.0.Bug 1249527 is still fixed, and I was able to build darcs with the compiler.Best Wishes,Greg___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.1 release candidate testing on OS X
Hi, ghc-6.4.1.20050804 builds successfully on Mac OS X 10.4.2 using gcc 3.3. This snapshot also appears to fix bug 1249527, runhaskell causes GHC to segfault on OS X. The new compiler was also tested by building darcs-1.0.3. The build was done under the darwinports infrastructure using ghc-6.4 as the bootstrap compiler. I haven't yet tried to build using gcc 4.0; should I expect that to work yet? Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error building GHC from darwin ports
Hi David, I maintain GHC under darwinports. You're more likely to get help for this (apparently DP specific) issue on the darwinports list. What seems to be happening is that your bootstrap compiler is not being found. Since this doesn't happen on my machine (10.4.1 with Xcode 2.1) I suspect there is a bug in darwinports 1.001 (I'm using the version from cvs HEAD). I think I may have suggested this before, but 1. run 'sudo port selfupdate' This will ensure you have the latest portfiles and infrastructure. 2. run 'sudo port -dv install ghc build.log 21' This will make a complete log of the build. Send me the log and I'll try again to diagnose the problem. As I said, I think a bug has crept into the released version of DP. The haskell portfile is a good stress test for the system and occasionally finds breakages. Best Wishes, Greg On Jun 17, 2005, at 1:22 AM, David Menendez wrote: I currently have GHC installed using darwin ports, and I've been trying to upgrade from 6.4_0 to 6.4_8, but I keep hitting a file-not-found error. Looking at the paths in question, I'm guessing the problem has to do with the path segment /var/db/dports/build/ file._opt_local_var_db_dports_sources_rsync.rsync. opendarwin.org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/ appearing twice. Unfortunately, I don't understand the makefiles well enough to track down where this is happening. I'm running Mac OS X 10.4 with XCode 2.0 and darwinports 1.001. Here are the relevant errors: - /opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc -M -optdep-f -optdep.depend -osuf o-H16m -O -I/usr/include -I/opt/local/ include -L/usr/lib -L/opt/local/lib -cpp -fglasgow-exts -O AbsSyn.lhs First.lhs GenUtils.lhs GetOpt.lhs Grammar.lhs Info.lhs LALR.lhs Lexer.lhs Main.lhs ParseMonad.lhs Parser.hs ProduceCode.lhs ProduceGLRCode.lhs Set.lhs Target.lhs Version.hs /opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc: line 5: /opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/var/db/dports/build/ file ._opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/lib/ghc-6.4/ ghc-6.4: No such file or directory /opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc: line 5: exec: /opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/var/db/dports/build/ file ._opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/lib/ghc-6.4/ghc-6.4: cannot execute: No such file or directory gmake[2]: *** [depend] Error 126 gmake[1]: *** [boot] Error 1 gmake[1]: Leaving directory `/opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-6.4/happy' gmake: *** [/opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-6.4/happy/src/happy-inplace] Error 2 Warning: the following items did not execute (for ghc): com.apple.destroot com.apple.build Error: Unable to upgrade port: 1 -- David Menendez [EMAIL PROTECTED] | In this house, we obey the laws http://www.eyrie.org/~zednenem |of thermodynamics! ___ 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: Error building GHC from darwin ports
Hi David,
I think I have an idea of what is happening. Recent changes to DP
have moved the work directories to new locations (inside ${prefix}/var),
symlinked to the old location. This can mess up ports that unpack
multiple tarballs in the work directory.
I'll let you know when I have a fix.
Greg
On Jun 17, 2005, at 1:22 AM, David Menendez wrote:
I currently have GHC installed using darwin ports, and I've been
trying
to upgrade from 6.4_0 to 6.4_8, but I keep hitting a file-not-found
error. Looking at the paths in question, I'm guessing the problem
has to
do with the path segment
/var/db/dports/build/
file._opt_local_var_db_dports_sources_rsync.rsync.
opendarwin.org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/ appearing
twice.
Unfortunately, I don't understand the makefiles well enough to track
down where this is happening. I'm running Mac OS X 10.4 with XCode 2.0
and darwinports 1.001.
Here are the relevant errors:
-
/opt/local/var/db/dports/build/file.
_opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc -M -optdep-f
-optdep.depend -osuf o-H16m -O -I/usr/include -I/opt/local/
include
-L/usr/lib -L/opt/local/lib -cpp -fglasgow-exts -O AbsSyn.lhs
First.lhs
GenUtils.lhs GetOpt.lhs Grammar.lhs Info.lhs LALR.lhs Lexer.lhs
Main.lhs
ParseMonad.lhs Parser.hs ProduceCode.lhs ProduceGLRCode.lhs Set.lhs
Target.lhs Version.hs
/opt/local/var/db/dports/build/file.
_opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc: line 5:
/opt/local/var/db/dports/build/file.
_opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/var/db/dports/build/
file
._opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/lib/ghc-6.4/
ghc-6.4: No
such file or directory
/opt/local/var/db/dports/build/file.
_opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc: line 5: exec:
/opt/local/var/db/dports/build/file.
_opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/var/db/dports/build/
file
._opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/lib/ghc-6.4/ghc-6.4:
cannot execute: No such file or directory
gmake[2]: *** [depend] Error 126
gmake[1]: *** [boot] Error 1
gmake[1]: Leaving directory
`/opt/local/var/db/dports/build/file.
_opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-6.4/happy'
gmake: ***
[/opt/local/var/db/dports/build/file.
_opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-6.4/happy/src/happy-inplace]
Error
2
Warning: the following items did not execute (for ghc):
com.apple.destroot com.apple.build
Error: Unable to upgrade port: 1
--
David Menendez [EMAIL PROTECTED] | In this house, we obey the
laws
http://www.eyrie.org/~zednenem |of thermodynamics!
___
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: Error building GHC from darwin ports
David, Try 'sudo port clean ghc' and then 'sudo port -dv install ghc'. The bootstrap compiler script is edited automatically by the portfile so it points to the proper location of the executable. If you interrupt the build for any reason and restart it (without cleaning) you can have the path expanded twice, which would explain what you are seeing. Best Wishes, Greg On Jun 17, 2005, at 1:22 AM, David Menendez wrote: I currently have GHC installed using darwin ports, and I've been trying to upgrade from 6.4_0 to 6.4_8, but I keep hitting a file-not-found error. Looking at the paths in question, I'm guessing the problem has to do with the path segment /var/db/dports/build/ file._opt_local_var_db_dports_sources_rsync.rsync. opendarwin.org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/ appearing twice. Unfortunately, I don't understand the makefiles well enough to track down where this is happening. I'm running Mac OS X 10.4 with XCode 2.0 and darwinports 1.001. Here are the relevant errors: - /opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc -M -optdep-f -optdep.depend -osuf o-H16m -O -I/usr/include -I/opt/local/ include -L/usr/lib -L/opt/local/lib -cpp -fglasgow-exts -O AbsSyn.lhs First.lhs GenUtils.lhs GetOpt.lhs Grammar.lhs Info.lhs LALR.lhs Lexer.lhs Main.lhs ParseMonad.lhs Parser.hs ProduceCode.lhs ProduceGLRCode.lhs Set.lhs Target.lhs Version.hs /opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc: line 5: /opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/var/db/dports/build/ file ._opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/lib/ghc-6.4/ ghc-6.4: No such file or directory /opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc: line 5: exec: /opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/var/db/dports/build/ file ._opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/lib/ghc-6.4/ghc-6.4: cannot execute: No such file or directory gmake[2]: *** [depend] Error 126 gmake[1]: *** [boot] Error 1 gmake[1]: Leaving directory `/opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-6.4/happy' gmake: *** [/opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-6.4/happy/src/happy-inplace] Error 2 Warning: the following items did not execute (for ghc): com.apple.destroot com.apple.build Error: Unable to upgrade port: 1 -- David Menendez [EMAIL PROTECTED] | In this house, we obey the laws http://www.eyrie.org/~zednenem |of thermodynamics! ___ 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: Error building ghc 6.4 under os x
On May 5, 2005, at 2:03 AM, Jeffrey Vaughan wrote: Thanks for the quick reply:) Gregory Wright wrote: Or just download and install the darwinports system and type sudo port install ghc Unfortunately this isn't working for me. It appears that port is attempting to download ghc-6.4-darwin-bootstrap.tar.bz2 which does not exists. However this is a ghc-6.4-darwin-bootstrap-v01.tar.bz2. Where did you get your copy of darwinports? The -v01 bootstrap file has been in use for several months. And after installing, did you run sudo port -d selfupdate to ensure you had the latest portfiles? I changed Portfile to reflect this, and the build died later in the process. I'm currently waiting for xcode 1.5 to download, but i'm pretty sure the above is a bug. Not surprising, since somehow you got a very outdated port file. Send me the portfile you tried and I'll try to get an idea of what happened. If you didn't have the Xcode 1.5 tools + updates, building ghc from source was almost certainly bound to fail. -Greg --Jeff On May 4, 2005, at 9:03 PM, Jeffrey Vaughan wrote: Hi All, I'm trying to build ghc 6.4 on mac os x (10.3) using ghc 6.2. The build dies with /tmp/ghc18478.hc:3:17: Stg.h: No such file or directory. An abridged session transcript is below. ___ 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: Error building ghc 6.4 under os x
Jeff, Mmaybe I was right about the portfile not being up to date. The latest does indeed refer to -v01, and the haskell ftp site has the -v01 bootstrap compiler (just checked!). Send me your portfile, along with a transcript of the sudo port -dv install output. Greg On May 5, 2005, at 2:03 AM, Jeffrey Vaughan wrote: Thanks for the quick reply:) Gregory Wright wrote: Or just download and install the darwinports system and type sudo port install ghc Unfortunately this isn't working for me. It appears that port is attempting to download ghc-6.4-darwin-bootstrap.tar.bz2 which does not exists. However this is a ghc-6.4-darwin-bootstrap-v01.tar.bz2. I changed Portfile to reflect this, and the build died later in the process. I'm currently waiting for xcode 1.5 to download, but i'm pretty sure the above is a bug. --Jeff On May 4, 2005, at 9:03 PM, Jeffrey Vaughan wrote: Hi All, I'm trying to build ghc 6.4 on mac os x (10.3) using ghc 6.2. The build dies with /tmp/ghc18478.hc:3:17: Stg.h: No such file or directory. An abridged session transcript is below. ___ 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: Error building ghc 6.4 under os x
Hi Jeffrey, Using the darwinports infrastructure we successfully built ghc-6.4 using ghc-6.2.2; you might look at the port file to get an idea of how the build procedure had to be arranged to make it work. (The port file is a tcl script but it is pretty self-explanatory which parts specify the arguments to configure, etc.) Look at http:// darwinports.opendarwin.org for more information. Or just download and install the darwinports system and type sudo port install ghc and you'll get a build from source. It takes about 4 hours on a 1.5 GHz powerbook G4. For a good time, specify the verbose debugging flags and you can watch the build go by: sudo port -dv install ghc Note that you should be using Xcode 1.5 with all the updates, including the gcc update from the end of 2004. You might also have to upgrade to gnu make 3.80 to avoid a bug in gmake 3.79 which can cause gmake to fall into an infinite loop. The darwinports build takes care of this for you. Best Wishes, Greg On May 4, 2005, at 9:03 PM, Jeffrey Vaughan wrote: Hi All, I'm trying to build ghc 6.4 on mac os x (10.3) using ghc 6.2. The build dies with /tmp/ghc18478.hc:3:17: Stg.h: No such file or directory. An abridged session transcript is below. Any ideas about what's going on? Thanks! --Jeff [EMAIL PROTECTED] ghc-6.4 # autoreconf [EMAIL PROTECTED] ghc-6.4 # ./configure [seems to work file] [EMAIL PROTECTED] ghc-6.4 # make -- -- ===fptools== Recursively making `boot' in mkdependC mkdirhier runstdtest lndir ... PWD = /usr/local/ghc-6.4/glafp-utils -- -- -- -- ==fptools== make boot -r; in /usr/local/ghc-6.4/glafp-utils/mkdependC -- -- -- -- ==fptools== make boot -r; in /usr/local/ghc-6.4/glafp-utils/mkdirhier -- -- -- -- ==fptools== make boot -r; in /usr/local/ghc-6.4/glafp-utils/runstdtest -- -- -- -- ==fptools== make boot -r; in /usr/local/ghc-6.4/glafp-utils/lndir -- -- ../../glafp-utils/mkdependC/mkdependC -f .depend -- -O -- lndir.c -- -- ===fptools== Finished making `boot' in mkdependC mkdirhier runstdtest lndir ... PWD = /usr/local/ghc-6.4/glafp-utils -- -- -- -- ===fptools== Recursively making `all' in mkdependC mkdirhier runstdtest lndir ... PWD = /usr/local/ghc-6.4/glafp-utils -- -- -- -- ==fptools== make all -r; in /usr/local/ghc-6.4/glafp-utils/mkdependC -- -- make[2]: Nothing to be done for `all'. -- -- ==fptools== make all -r; in /usr/local/ghc-6.4/glafp-utils/mkdirhier -- -- make[2]: Nothing to be done for `all'. -- -- ==fptools== make all -r; in /usr/local/ghc-6.4/glafp-utils/runstdtest -- -- make[2]: Nothing to be done for `all'. -- -- ==fptools== make all -r; in /usr/local/ghc-6.4/glafp-utils/lndir -- -- make[2]: Nothing to be done for `all'. -- -- ===fptools== Finished making `all' in mkdependC mkdirhier runstdtest lndir ... PWD = /usr/local/ghc-6.4/glafp-utils -- -- -- -- ===fptools== Recursively making `boot' in includes lib utils driver docs compiler rts ... PWD = /usr/local/ghc-6.4/ghc -- -- -- -- ==fptools== make boot -r; in /usr/local/ghc-6.4/ghc/includes -- --
ghc-6.5 (development version) for Mac OS X
HI, For darwinports users on Mac OS X who just have to live on the bleeding edge, a new port of the development version of GHC is available. It builds from the latest cvs. (So you take your chances. There's no guarantee that the build process will work, not trash your machine, not render your city a smoking, radiating ruin or change the signature of the spacetime metric. Although the last two are believed unlikely.) The executables all have the suffix -6.5, so you can install along with your regular ghc without conflict. For more information on darwinports, see http://darwinports.opendarwin.org Best Wishes, Greg Gregory Wright ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Updates for Mac OS X users using Darwinports
Hi, Users of Mac OS X/Darwinports will find new portfiles for ghc (ghc-6.4), nhc98 (nhc-1.18) and hugs98 (March 2005 release). The hmake port has been bumped to version 3.10 and a new port of cpphs (version 0.9) has been added. The darwinports system builds from source, although progress is being made on extending it to provide binary packages as well. A new ghc-devel port will be available soon for those who want to live on the bleeding edge. Thanks to Malcolm Wallace for ironing out some last minute issues with nhc98. Best Wishes, Greg Gregory Wright ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
