A number of features are being blindly enabled on python that aren't correct from a porting standpoint; a handful in configure.in I noticed are:

# The later defininition of _XOPEN_SOURCE disables certain features
# on Linux, so we need _GNU_SOURCE to re-enable them (makedev, tm_zone).
AC_DEFINE(_GNU_SOURCE, 1, [Define on Linux to activate all library features])

# The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables
# certain features on NetBSD, so we need _NETBSD_SOURCE to re-enable
# them.
AC_DEFINE(_NETBSD_SOURCE, 1, [Define on NetBSD to activate all library features])

# The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables
# certain features on FreeBSD, so we need __BSD_VISIBLE to re-enable
# them.
AC_DEFINE(__BSD_VISIBLE, 1, [Define on FreeBSD to activate all library features])

# The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables
# u_int on Irix 5.3. Defining _BSD_TYPES brings it back.
AC_DEFINE(_BSD_TYPES, 1, [Define on Irix to enable u_int])

# The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables
# certain features on Mac OS X, so we need _DARWIN_C_SOURCE to re-enable
# them.
AC_DEFINE(_DARWIN_C_SOURCE, 1, [Define on Darwin to activate all library features])

these are only applicable on certain platforms and thus, shouldn't be enabled on all platforms (the default should be off, and then the values should be tuned according to the platform detection performed by autoconf).

Garrett, does the bug still exist in 3.2 (branch named py3k in subversion)?

doko, I made you nosy because of your autotools expertise. Hope it’s okay.

The issue is still present.

The overall problem I suppose is with consistency and presentation of features in the python language.

Many features cannot be presented in a 100% portable manner, and the problem is that such features that aren't POSIX conforming should be 100% spelled out instead of being implied functional on all Unix based platforms.

So, again... if these platforms can't function with these preprocessor defines, the platforms need to be fixed -- not python.

From msg112274 "if these platforms can't function with these preprocessor defines, the platforms need to be fixed -- not python." so I believe this can be closed.

This issue has been superseded by other work.