Re: coreutils failure on Mac OS X 10.5

[Jim Meyering]

Peter O'Gorman <address@hidden> wrote:
> I am pretty sure that this is still the case with latest gnulib, but
> have not checked.
>
> Coreutils fails to build on Mac OS X 10.5. Apple has worked hard to make
> this version of Mac OS X UNIX(tm). To do so they had to change the
> behavior of a number of functions. In order to maintain binary
> compatibility with older releases they kept the old symbol names in libc
> and named any functions that had to be modified to conform to the
> standard symbol$UNIX2003. So libc has a putenv symbol and a
> putenv$UNIX2003 symbol, the former behaves like BSD putenv, the latter
> is unix03 conforming. When you #include <stdlib.h>, unless you #define
> _NONSTD_SOURCE, the symbol putenv is renamed, using asm, to putenv$UNIX2003.
>
> What, you ask, does this have to do with gnulib? Well, when attempting
> to compile GNU coreutils, we noticed that it was failing with undefined
> symbols, specifically '_rpl_putenv$UNIX2003' (all C symbols on Mac OS X

Thanks for the report.
Have you tried with a recent coreutils snapshot?

Can you provide more details?
Like is this a link error?
What is trying to use that symbol?

> are prefixed with an underscore). What is happening, of course, is that
> the #define putenv rpl_putnev is combining with Apple's magic in the
> headers to give us a symbol that does not exist.
>
> Note that in this particular case, the gnulib check for putenv checks
> that putenv("VAR") removes VAR from the environment. As far as I can
> tell, this is a non-standard extension that is only available on
> linux/glibc systems. Shouldn't people be using unsetenv for this?
>
> Anyway, a quick hack fix, is to do ./configure ...
> jm_cv_func_svid_putenv=yes ... for coreutils. So far the issue has only

BTW, I will to rename all of those jm_ symbols to use the gl_ prefix.
But not for a few weeks.

> been seen with coreutils and putenv, even though there are a fairly
> large number of functions that get the renaming to $UNIX03 in the
> headers, so it may be that the best short term solution is to change the
> gnulib putenv check.