Build failures on Mac OS X 10.5
Deborah Goldsmith
goldsmit at apple.com
Tue May 22 19:01:38 EDT 2007
OK, I redid it:
1. Recreate source distribution from tar.bz2 downloads in new directory
2. Move in mk/build.mk to work around splitter incompatibility with
Leopard
3. ./configure
3. make
It still crashes in the same 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
in the same way:
Process: ghc-6.6.1 [3655]
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 [3457]
Date/Time: 2007-05-22 15:54:06.011 -0700
OS Version: Mac OS X 10.5 (9A446)
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: 0x01148b40 esi: 0x01148b38 ebp: 0x0264e924 esp: 0xbfffd4e0
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 ??? (???)
<86ce72f02577fae2f8266dc0239744af> /Volumes/Totoro/source/ghc-6.6.1/
compiler/stage1/ghc
-6.6.1
0xe69000 - 0xeaefff +GMP ??? (???) /Library/Frameworks/
GMP.framework/Versions/A/GMP
0x8fe00000 - 0x8fe2bff8 dyld 84.0 (???)
<b289815b39c9e37e061530b97617d5f3> /usr/lib/dyld
0x9049f000 - 0x904a6fed libgcc_s.1.dylib ??? (???)
<62f15ce2792a1b8cd6505ccf778e6cab> /usr/lib/libgcc_s.1.dylib
0x910ac000 - 0x911f2fe8 libSystem.B.dylib ??? (???)
<1a04d9c7751575fb6fdd1f292f33a405> /usr/lib/libSystem.B.dylib
0x95953000 - 0x95955fe7 libmathCommon.A.dylib ??? (???) /usr/lib/
system/libmathCommon.A.dylib
0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/
libSystem.B.dylib
The session is attached.
Thanks,
Deborah
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CleanMake10-5.txt.bz2
Type: application/octet-stream
Size: 37217 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20070522/82de39ab/CleanMake10-5.txt.obj
-------------- next part --------------
On May 22, 2007, at 12:41 AM, Thorkil Naur wrote:
> Hello,
>
> On Tuesday 22 May 2007 04:22, Deborah Goldsmith wrote:
>> Here is the output:
>>
>>
> ...
>> The mk/build.mk consists of:
>>
>> SplitObjs = NO
>>
>> to work around another problem.
>>
>> Note that this source is not pulled from darcs: it's the source
>> distribution of 6.6.1, downloaded from the web site.
>>
>> Any suggestions on where to look next would be appreciated.
>>
>> Thanks,
>> Deborah
>>
>
> Thanks a lot, this is very useful. The "sh boot" is said on
>
> http://hackage.haskell.org/trac/ghc/wiki/Building/QuickStart
>
> not to be needed if you have a source distribution, so I guess it
> makes sense
> in your case that "sh boot" fails to find the boot script.
>
> The thing I would suggest next is to clean out the build tree with
> "make
> distclean" and then do the "./configure" and "make" all over again.
> It is my
> experience (and others' as well, I believe) that the GHC build
> system is
> somewhat brittle, in the sense that many dependencies are not
> really taken
> into account when deciding what to rebuild in a specific situation.
> There are
> many good reasons for this, but in any case, that's the way it is.
>
> That would be very useful, thanks, and then let's see what happens.
>
> Best regards
> Thorkil
>
>> On May 21, 2007, at 4:56 AM, Thorkil Naur wrote:
>>
>>> Hello,
>>>
>>> Without any idea what is going on here, the best I can suggest is
>>> that you
>>> make available, somehow, the complete output that results from
>>> following
>>>
>>> http://hackage.haskell.org/trac/ghc/wiki/Building/Rebuilding
>>>
>>> i.e. "make distclean", "sh boot", "./configure", and "make", with
>>> whatever
>>> parameters you use. In addition, a copy of the mk/build.mk that you
>>> use (if
>>> any). Then I can compare with what I usually see and, with a bit of
>>> luck,
>>> something may turn up.
>>>
>>> Thanks and best regards
>>> Thorkil
>>>
>>> On Monday 21 May 2007 11:46, Simon Marlow wrote:
>>>> Hi Deborah,
>>>>
>>>> I don't have any specific information on this particular crash, or
>>>> the other
>>>> one. We do have some instructions for debugging, however:
>>>>
>>>> http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes
>>>>
>>>> Any other MacOS X experts have anything to offer here?
>>>>
>>>> Cheers,
>>>> Simon
>>>>
>>>> Deborah Goldsmith wrote:
>>>>> 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