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 > >>>>> > >>>> > >>> > >>> > >> > >> > _______________________________________________ Glasgow-haskell-bugs mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
