Build failures on Mac OS X 10.5

[Deborah Goldsmith]

Here is more detailed crash information, FWIW:

Process:         ghc-6.6.1 [37476]
Path:            /Volumes/Totoro/source/ghc-6.6.1/compiler/stage1/ 
ghc-6.6.1
Identifier:      ghc-6.6.1
Version:         ??? (???)
Code Type:       X86 (Native)
Parent Process:  make [37340]

Date/Time:       2007-05-18 13:09:38.973 -0700
OS Version:      Mac OS X 10.5 (9A441)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: 0x000000000000000d, 0x0000000000000000
Crashed Thread:  0

Thread 0 Crashed:
0   ghc-6.6.1                           0x007437b7 sbuE_info + 15

Thread 0 crashed with X86 Thread State (32-bit):
   eax: 0x007437a8  ebx: 0x008ca008  ecx: 0x011b71bc  edx: 0xffffc002
   edi: 0x011df1b8  esi: 0x011df1b0  ebp: 0x02053c78  esp: 0xbfffcf10
    ss: 0x0000001f  efl: 0x00010206  eip: 0x007437b7   cs: 0x00000017
    ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
   cr2: 0x004a6d18

Binary Images:
     0x1000 -   0x82dff7 +ghc-6.6.1 ??? (???)  
<d12a8b5830ee3fbc0948df855328fad8> /Volumes/Totoro/source/ghc-6.6.1/ 
compiler/stage1/ghc
-6.6.1
   0xe4d000 -   0xe92fff +GMP ??? (???) /Library/Frameworks/ 
GMP.framework/Versions/A/GMP
0x8fe00000 - 0x8fe2c008  dyld 84.0 (???)  
<eb2d7669f9ba168508e541219dc55fae> /usr/lib/dyld
0x91b63000 - 0x91ca8fe0  libSystem.B.dylib ??? (???)  
<43e841444da46670e61de0dc8bd7a2ff> /usr/lib/libSystem.B.dylib
0x92df4000 - 0x92df6fe7  libmathCommon.A.dylib ??? (???) /usr/lib/ 
system/libmathCommon.A.dylib
0x94e6e000 - 0x94e75fed  libgcc_s.1.dylib ??? (???)  
<1b0a4147d838c7cdc644818e0d15ec25> /usr/lib/libgcc_s.1.dylib
0xffff0000 - 0xffff1780  libSystem.B.dylib ??? (???) /usr/lib/ 
libSystem.B.dylib

Any suggestions for how to proceed at this point?

Thanks,
Deborah

On May 17, 2007, at 8:44 PM, Deborah Goldsmith wrote:

> 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
>