Build failures on Mac OS X 10.5

[Deborah Goldsmith]

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 <goldsmit at apple.com> 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 at haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs