[Python-Dev] red buildbots on 2.7

Alexander Belopolsky alexander.belopolsky at gmail.com
Wed Jun 23 16:06:27 CEST 2010


On Wed, Jun 23, 2010 at 2:08 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
..
> I don't agree.  The patch itself is pretty simple, but it does make a rather significant change to the build process: the
> compile-time environment in configure would be different than during the compilation of posixmodule. That is, in functions
> that check for features (the HAVE_FOOBAR macros in pyconfig.h) would use _DARWIN_C_SOURCE while posixmodule
> itself wouldn't.    This may lead to subtle bugs, or even compile errors (because some function definitions change when
> _DARWIN_C_SOURCE active).

I agree.  Messing with compatibility macros outside of pyconfig.h is
not a good idea.  Martin's hack, while likely to work in most cases,
is still a hack.  I believe, however we can undefine _DARWIN_C_SOURCE
globally at least on 10.4 and higher.  I grepped throught the headers
on my 10.6 system and I notice that the majority of checks for
_DARWIN_C_SOURCE are in the form of

#if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)

According to a comment in configure,

  # On Mac OS X 10.4, defining _POSIX_C_SOURCE or _XOPEN_SOURCE
  # disables platform specific features beyond repair.
  # On Mac OS X 10.3, defining _POSIX_C_SOURCE or _XOPEN_SOURCE
  # has no effect, don't bother defining them

_POSIX_C_SOURCE is already undefined in python headers, so undefining
_DARWIN_C_SOURCE will have no effect on the majority of checks.

I was able to find very few exceptions:  some cases check
_XOPEN_SOURCE instead or in addition to _POSIX_C_SOURCE before
ignoring _DARWIN_C_SOURCE:

/usr/include/grp.h:#if !defined(_XOPEN_SOURCE) || defined(_DARWIN_C_SOURCE)
/usr/include/pwd.h:#if (!defined(_POSIX_C_SOURCE) &&
!defined(_XOPEN_SOURCE)) || defined(_DARWIN_C_SOURCE)
..

Since _XOPEN_SOURCE is similarly undefined in python headers, these
cases are unaffected as well.

This leaves a handful of cases where Apple provides additional macros
for fine grained control:

/usr/include/stdio.h:#if defined(__DARWIN_10_6_AND_LATER) &&
(defined(_DARWIN_UNLIMITED_STREAMS) || defined(_DARWIN_C_SOURCE))
/usr/include/unistd.h:#if defined(_DARWIN_UNLIMITED_GETGROUPS) ||
defined(_DARWIN_C_SOURCE)

The second line above is our dear friend and the _DARWIN_C_SOURCE
behavior conditioned on the first line can be enabled by defining
_DARWIN_UNLIMITED_STREAMS macro.

I believe _DARWIN_C_SOURCE casts its net to wide and more targeted
macros should be used instead.

..
>     Defining _POSIX_C_SOURCE or _DARWIN_C_SOURCE causes library and kernel calls to conform
>     to the SUSv3 standards even if doing so would alter  the behavior of functions used in 10.3.

I cannot reconcile this with !defined(_POSIX_C_SOURCE) ||
defined(_DARWIN_C_SOURCE) logic that I see in the headers.


More information about the Python-Dev mailing list