Hi,
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
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
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.
Any other suggestions?
Peter
