Build failures on Mac OS X 10.5

[Deborah Goldsmith]

OK, setting SplitObjs = NO got it past that compilation error, so it  
must be the splitter script as you suggest. Unfortunately, there was  
a subsequent error: the stage1 compiler crashed building stage 2:

../compiler/stage1/ghc-inplace -H16m -O  -istage2/utils  -istage2/ 
basicTypes  -istage2/types  -istage2/hsSyn  -istage2/prelude  - 
istage2/rename  -istage2/typecheck  -istage2/deSugar  -istage2/ 
coreSyn  -istage2/specialise  -istage2/simplCore  -istage2/stranal  - 
istage2/stgSyn  -istage2/simplStg  -istage2/codeGen  -istage2/main  - 
istage2/profiling  -istage2/parser  -istage2/cprAnalysis  -istage2/ 
ndpFlatten  -istage2/iface  -istage2/cmm  -istage2/nativeGen  - 
istage2/ghci -Istage2 -DGHCI -DBREAKPOINT -package template-haskell - 
threaded -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser - 
package unix -package Cabal -package regex-compat -ignore-package  
lang -recomp -Rghc-timing  -H16M '-#include "cutils.h"' -package- 
name  ghc-6.6.1   -fgenerics    -c ghci/ByteCodeGen.lhs -o stage2/ 
ghci/ByteCodeGen.o  -ohi stage2/ghci/ByteCodeGen.hi
make[2]: *** [stage2/ghci/ByteCodeGen.o] Segmentation fault
make[1]: *** [stage2] Error 2
make: *** [bootstrap2] Error 2

I'll be happy to do any other investigation anyone suggests.

Thanks,
Deborah

On May 8, 2007, at 2:29 AM, Simon Marlow wrote:

> Deborah Goldsmith wrote:
>
> > Actually, I'm not sure that's what's going on. The unresolved symbol
> > error is:
> >
> >> ../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude
> >> -"#include" HsBase.h -funbox-strict-fields -package-name   
> base-2.1.1
> >> -O -Rghc-timing -fgenerics  -fgenerics -split-objs    -c
> >> Foreign/C/Error.hs -o Foreign/C/Error.o  -ohi Foreign/C/Error.hi
> >> /tmp/ghc78351_0/ghc78351_0.split__108.s:unknown:Undefined local  
> symbol
> >> L_strerror$UNIX2003$stub
> >
> > So the reference actually is to the version *with* $UNIX2003  
> appended.
> > Also, both strerror and strerror$UNIX2003 are present in the library
> > being linked against, so if the FFI were going straight to  
> strerror (old
> > version), it would find it, because it's still there for  
> compatibility.
> >
> > The only way that a symbol like L_strerror$UNIX2003$stub would be
> > generated would be if someone *were* including unistd.h. There's  
> no way
> > the $UNIX2003 would creep in otherwise. Also, it says it's a "local
> > symbol." Also note the leading L; I would expect the symbol to be
> > _strerror$UNIX2003$stub. The actual symbols exported by
> > /usr/lib/libSystem.dylib in 10.5 are:
> >
> > 0000c59c T _strerror
> > 000b7fb4 T _strerror$UNIX2003
>
> Ok, then we'll have to dig further.  Suggestions:
>
>   - turn off splitting: add SplitObjs=NO to mk/build/mk.  If this  
> makes
>     the error go away, then the problem is likely in the split script
>     (driver/split/ghc-split.lprl).
>
>   - If the error is still there without splitting, then compile the
>     module with -keep-tmp-files, and take a look at the .s and .raw_s
>     files to see where the local symbol is coming from.
>
> Cheers,
> 	Simon