Philip K.F. Hölzenspies:
I'm trying toupdate the Portfile so that ghc-6.8.2 can be built using MacPorts (handy for installing other ghc-dependent material from MacPorts like gtk2hs). The problem seems to be that the available bootstrap binary http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin-bootstrap.tar.... causes a segfault on Leopard (below are the steps I took in my attempt to build ghc with this bootstrap binary).
Using Manuel Chakravarty's binary distribution of ghc-6.8.1-i386- apple-darwin building ghc-6.8.2 works fine. It seemed to me that the easiest way to fix the bootstrap problem is to boot from C as described on the wiki (http://hackage.haskell.org/trac/ghc/wiki/Building/Porting). Two things were wrong, however.
make hc-file-bundle
Making the hc-file-bundle target failed, because not all rts/*.cmm had rts/*.hc counterparts after the build. The make fails because of this fragment from the Makefile (part of the hc-file-bundle target, starting from line 513):
for f in `$(FIND) ghc-$(ProjectVersion)/compiler ghc-$(ProjectVersion)/rts -name "*.cmm" -follow -print` ""; do \ if test "x$$f" !=3D "x"; then \ echo `echo "$$f" | sed 's/cmm$$/hc/g' ` >> hc-files-to-go ; \ fi; \ done;
This adds some non-existing .hc files to the hc-files-to-go list that tar will not find, later on, causing an error. I just added a test to see whether the file exists. If it does not, I call make for that .hc file explicitly, which solves the problem for most files. The files that don't have a make target, I simply omitted from the hc-files-to-go. I haven't been able to test the severity of this, because of the second problem.
I am not sure what the problem is here. Simon? Ian?
checking for ld... /usr/bin/ld checking for path to top of build tree... ./configure: line 2651: - v0: command not found ./configure: line 2655: utils/pwd/pwd: No such file or directory configure: error: cannot determine current directory
Upon inspection of the configure script, I found out that line 2651 uses the variable designating the ghc compiler.
This is due to a change of the configure stage that AFAIK was made to easy building on windows. Instead, of using shell commands/scripts (as GHC did previously) to obtain some configuration information (here the file path at which the top of the GHC build tree is located), the build system now uses small Haskell programs/scripts. This makes the build more portable ** if there is already a Haskell compiler on the system **. It however messes everything up if you want to build from HC files (and so don't have a Haskell compiler). I am not sure whether anybody thought about this problem when the change to using Haskell scripts instead of shell scripts was made. Ian? Simon? The only solution that I see is to replace the Haskell scripts by vanilla shell scripts in HC bundles. Even if that causes problems on windows (without cygwin), it would make HC bundles viable on Unix systems again. Manuel