On Dec 31, 2006, at 8:28 , Brandon S. Allbery KF8NH wrote:
The problem people have been having with ghci on FreeBSD turns out to be a bootstrapping issue: (...)
There seems to be a little confusion about this, from discussions on the IRC channel and in private mail; my apologies, I was insomniac while sending that message, and was less than clear as a result. This is not a GHC bug; it's a problem with the way the FreeBSD "ports" infrastructure is using the bootstrap compiler. (And my problem statement was slightly incorrect, it turns out; the bootstrap ghc-pkg is there, but is not where ghc/configure can see it.) My patch is not a fix; it's a quick hack that stubs out the failing configure test, and is very much not suitable for official distribution. A better fix is to use the bootstrap ghc-pkg, but there are complications (in particular, the bootstrap wants a libgmp shared library; I'm failing to understand why the final build isn't using a libgmp.so at all, or how the bootstrap ghc is getting around the same issue). I've since checked the FreeBSD bug database for outstanding bugs against the lang/ghc port, and determined that neither this problem nor an update to GHC 6.6 are in the queue. I've filed a proper bug report (detailing the actual problem and suggesting possible (actual, as opposed to my hack) fixes, leaving it up to the port maintainer to decide how to fix it properly). I am undecided as to whether to follow up with an update to GHC 6.6. There are some complications here as well: * FreeBSD ports is currently in "slush" (not quite a freeze...) pending 6.2-RELEASE, and will likely remain so for the next few weeks due to unexpected delays in the release process; * I'll probably have to work out that proper fix for the readline issue first, instead of leaving it to the maintainer; * Since GHC 6.6 is not fully backward compatible with 6.4.2, updating will probably require requesting a repocopy of lang/ghc to lang/ ghc642 and updating ports depending on it to point to the copy, then filing update bug reports against those dependents. This is probably better handled by the port maintainer, given ports update protocols. Given the above, probably I'll just request that the maintainer update the port when convenient. -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH