Build failures on Mac OS X 10.5
Deborah Goldsmith
goldsmit at apple.com
Fri May 18 19:30:20 EDT 2007
I replaced the binary 6.6 distribution I was using with the 6.6.1 Mac
OS X Intel binary distribution from Christian Maeder, then tried
again. It now crashes in a different place:
../../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 -c GHC/Float.lhs -o GHC/
Float.o -ohi GHC/Float.hi
make[2]: *** [GHC/Float.o] Segmentation fault
Finished making all in base: 0
Here is the crash report:
Process: ghc-6.6.1 [83545]
Path: /Volumes/Totoro/source/ghc-6.6.1-build/compiler/
stage1/ghc-6.6.1
Identifier: ghc-6.6.1
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: make [83345]
Date/Time: 2007-05-18 16:21:23.334 -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 0x00750f7f sbqE_info + 15
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x00750f70 ebx: 0x008da008 ecx: 0x00000002 edx: 0xffffc002
edi: 0x02111b40 esi: 0x02111b38 ebp: 0x0264f924 esp: 0xbfffd4a0
ss: 0x0000001f efl: 0x00010216 eip: 0x00750f7f cs: 0x00000017
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037
cr2: 0x004aff64
Binary Images:
0x1000 - 0x83cff3 +ghc-6.6.1 ??? (???)
<d9ea7b54cd7cd3d2bc459a9035e6fe28> /Volumes/Totoro/source/ghc-6.6.1-
build/compiler/stag
e1/ghc-6.6.1
0xe69000 - 0xeaefff +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
Deborah
On May 18, 2007, at 1:59 PM, Deborah Goldsmith wrote:
> 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
>>
>
More information about the Glasgow-haskell-bugs
mailing list