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
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
