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
