Still trying to build unregisterised for FreeBSD/amd64

[Ian Lynagh]

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