Hi Malcolm,
I believe what's going on here is that strerror has been changed for
better Unix conformance, under the control of the __DARWIN_UNIX03
preprocessor flag. This is something you'll see in 10.4.x too. Here's
an excerpt from /usr/include/unistd.h on 10.4.9:
#if __DARWIN_UNIX03
pid_t setpgrp(void) __DARWIN_ALIAS(setpgrp);
#else /* !__DARWIN_UNIX03 */
int setpgrp(pid_t pid, pid_t pgrp); /* obsoleted by
setpgid() */
#endif /* __DARWIN_UNIX03 */
where __DARWIN_ALIAS and __DARWIN_UNIX03 come from /usr/include/sys/
cdefs.h:
#if __DARWIN_UNIX03 && !defined(__LP64__)
#define __DARWIN_ALIAS(sym) __asm("_" __STRING(sym) "$UNIX2003")
#else
#define __DARWIN_ALIAS(sym)
#endif
The idea behind this is that if something is compiled with
__DARWIN_UNIX03 (for Unix 2003 conformance) it links to a version of
the routine with $UNIX2003 appended (for 32-bit architectures). If
not, it gets the old version (for compatibility). In 10.5, strerror()
now falls under this switch where it didn't in 10.4:
char *strerror(int) __DARWIN_ALIAS(strerror);
(In this case the function signature hasn't changed as it did with
setpgrp, but presumably the semantics have.)
I tried configuring GHC with:
./configure CFLAGS="-O2 -D__DARWIN_UNIX03=0"
but it didn't fix the problem for me.
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?
No great mystery. I can't say whether Apple is interested in Haskell,
but I am, and I've been learning it in my not-so-copious free time. I
ran into this when trying to build GHC on 10.5. We try to let open-
source developers know if there are problems in their projects on a
new version of Mac OS X, because we like the projects to work when
the new version comes out. :-)
If you can think of something to try I'll be happy to try it for you
and report back.
Thanks,
Deborah
On May 4, 2007, at 5:43 AM, Malcolm Wallace wrote:
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
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
