Deborah Goldsmith <[EMAIL PROTECTED]> wrote:
> /tmp/ghc78351_0/ghc78351_0.split__108.s:unknown:
> Undefined local symbol L_strerror$UNIX2003$stub
The standard unix symbol 'strerror' is imported by the base package
from module Foreign/C/Error.hs like this:
foreign import ccall unsafe "string.h" strerror :: Errno -> IO (Ptr CChar)
The corresponding prototype for 'strerror' in /usr/include/string.h
on MacOS 10.4.9 is:
char *strerror(int);
Which all looks like it matces up OK. I presume that in MacOS 10.5,
something in this area has changed to do with localisation, or
internationalisation. Perhaps 'strerror' is no longer implemented as a
function, but as a cpp macro. Perhaps 'strerror' is no longer
physically located in libc.dylib. Perhaps there are now conditional
sections around 'strerror' which mean that we need to set a
pre-processing symbol to select the appropriate version of the
prototype.
Can you give us any snippets from the Leopard version of
/usr/include/string.h that might confirm one of these hypotheses?
> I can't divulge any confidential information about Leopard but I did
> get an OK to work with you folks to try to isolate the cause of this
> problem. If it's on our side we'd like to fix it, and if it's on your
> side we'd like to help you be ready for Leopard.
Thanks for making contact. Can you tell us any more about why Apple is
starting to find Haskell of sufficient interest to try to solve these
issues?
Regards,
Malcolm
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
