Hi Gregory, On Thu, Mar 08, 2007 at 11:25:39AM -0500, Gregory Wright wrote:
I fixed up Linker.c by replacing the calls to mmap (which will need fixing up anyway on FreeBSD/amd64) with MAP_FAILED and copying the definitions of four relocation types for X86_64 from machine/elf.h on the target into do_Elf_Rela_relocations. (The build on the host complained that R_X86_64_64, R_X86_64_PC32, R_X86_64_32 and R_X86_64_32S were undefined.)
Anything that compiles should be fine until you want to get ghci working.
With this change, the build on the host was able to complete. Collecting the .hc files works too, but the Makefile is out of date and references a few files that no longer exist.
That sounds right - a couple of variants (e.g. debug) of one of the cmm files (AutoApply possibly) and one or two files that are in extralibs, if I remember correctly.
With a little hand editing, this is fixed and I have what I believe is a good set of .hc files.
Over on the target, I unpack the fresh ghc-6.6-src.tar.bz2 and drop the .hc files on top of it. On FreeBSD, gmp is usually installed by the ports system in / usr/local/lib, so I preface invocations of configure in distrib/hc-build by
CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib"
so that the installed gmp is picked up in the configuration. I also edit mk/bootstrap.mk to add -L/usr/local/lib to HC_LD_BOOT_OPTS, and also add
-lHSregex-compat -lHSregex-posix -lHSregex-base
to HC_BOOT_LIBS.
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). You should then be able to use --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib and the HC_BOOT_LIBS should already be fixed.
I also have to delete cabal-setup from the SUBDIRS in libraries/Cabal/ Makefile. Otherwise the build fails complaining that there is no rule to make Cabal-setup.o.
*nod*
I also have to change libraries/base/Makefile to not try to build Prim.hs.
Again, fixed in the branch.
With these changes, distrib/hc-build is ready to roll. It chugs along happily until it tries to build Linker.c (which I have copied over from the host, so it has the changes that I made there) and then ghc-inplace segfaults:
../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? 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). If you get stuck, please shout.
I am wondering what to try next. Could ghc-inplace on the target be crashing because of differences in say, ptr sizes on the host versus the target?
It's possible; the closer you can make the host and target the fewer problems you are likely to have.
Any help would be appreciated. Especially useful would be any comments on which parts of the instructions can be trusted and which may be bitrotted and needing revision.
I think they should pretty much work with the 6.6 branch, although I'm also not convinced by the "Don't worry if the build falls over in the RTS, we don't need the RTS yet." comment. Thanks Ian