Deborah Goldsmith wrote:
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 don't have a MacOS X machine here to investigate, but I can take a guess at
what the problem is. When GHC compiles using its built-in native code
generator, the names of functions mentioned in FFI declarations are taken
literally: nothing is reading /usr/include/unistd.h, so there's no way to make
the connection between strerror and strerror$UNIX2003. To justify this, we say
that the Haskell FFI is binding to the C ABI, not API.
The way to work around it is to add a stub C function to one of the C files in
the base package, e.g. HsBase.h. There are many such stubs there already, for C
functions that are implemented as macros. In most cases the C standard says
which functions are allowed to be implemented as macros, so we can use
appropriate stubs to forestall such issues, but changing the name with __asm
doesn't count as a macro (presumably that's why you guys did it this way?).
Cheers,
Simon
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
