[Python-Dev] red buildbots on 2.7 (original) (raw)

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 HAVEFOOBAR macros in pyconfig.h) would use DARWINCSOURCE while posixmodule itself wouldn't.    This may lead to subtle bugs, or even compile errors (because some function definitions change when DARWINCSOURCE 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 POSIXCSOURCE or DARWINCSOURCE 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