homepage

make failed on Mac OS X including sys/random.h
It looks to be caused by this commit: https://github.com/python/cpython/commit/1958527a2c5dda766b1917ab563622434b3dad0d
Restoring the removed ifdefs solves the problem (see github PR)
Official patch to follow
Failure message.
```
In file included from Python/random.c:16:
/usr/include/sys/random.h:37:32: error: unknown type name 'u_int'
void read_random(void* buffer, u_int numBytes);
 ^
/usr/include/sys/random.h:38:33: error: unknown type name 'u_int'
void read_frandom(void* buffer, u_int numBytes);
 ^
/usr/include/sys/random.h:39:33: error: unknown type name 'u_int'
int write_random(void* buffer, u_int numBytes);
 ^
3 errors generated.
make: *** [Python/random.o] Error 1
```

Pam, what version of macOS / OS X did this fail on?

Patch for fix

OSX: 10.11.6 (15G1212)
Xcode 8.2.1 Build version 8C1002

Argh! This is the third go-around on this problem, starting with the quick fix for macOS 10.12 in Issue28676 then on to Issue28932 where Benjamin added a more elaborate configure test when it broke OpenBSD, and now that causes builds on macOS versions earlier than 10.12 but newer than 10.4 or 10.5 to fail. (And, we haven't noticed it because, ATM, the only OS X buildbot active is a 10.4 one and the OpenBSD buildbot is down.) Benjamin, if you could have a look, please, if I don't get to it first.

I will say that, though my fix seems to work, it feels that the "right" place to put the fix is in ./configure. 
Sadly, I don't speak './configure', though I apparently remember enough C from 17 years ago to get this working.

So, if sys/random.h can't be included without error why does the configure check for it work?

Good question.
It looks like there are 3 defines getting checked:
HAVE_SYS_RANDOM_H and either HAVE_GETRANDOM or HAVE_GETENTROPY
The previous issue seemed to be that you could have HAVE_GETRANDOM and/or HAVE_GETENTROPY be set, but still not have a sys/random.h, so a check was added for HAVE_SYS_RANDOM_H. However, on macs, you can HAVE_SYS_RANDOM_H, but still not have either HAVE_GETRANDOM or HAVE_GETENTROPY.
This _probably_ implies that the sys/random.h that's present isn't conformant enough for the compiler settings and my mac's os and/or xcode.

New patch to make consistent wrt use of "defined()"

Right, my question is why does configure define HAVE_SYS_RANDOM_H if including sys/random.h causes an error?

I've dug into things some more.
In my mac environment, sys/random.h is pretty empty and doesn't actually seem to provide anything that Python/random.c uses. The compile error is a type error is because 'u_int' never gets typedef'd in the rest of the compile includes.
I think the bottom line is that sys/random.h on mac os is neither useful, nor required.
Below is the error again and I've attached my sys/random.h
```
In file included from Python/random.c:16:
/usr/include/sys/random.h:37:32: error: unknown type name 'u_int'
void read_random(void* buffer, u_int numBytes);
 ^
/usr/include/sys/random.h:38:33: error: unknown type name 'u_int'
void read_frandom(void* buffer, u_int numBytes);
 ^
/usr/include/sys/random.h:39:33: error: unknown type name 'u_int'
int write_random(void* buffer, u_int numBytes);
```

Here's a how-to for reproducing this bug on Sierra:
1. Install Xcode 7.3.1 (All 7.x should be fine)
2. ./configure --enable-universalsdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
3. make
On Benjamin's question:
> why does configure define HAVE_SYS_RANDOM_H if including sys/random.h causes an error?
autoconf defines several "default includes". For example in line 592 of configure:
#ifdef HAVE_SYS_TYPES_H
# include <sys/types.h>
#endif
And in line 5559:
# On IRIX 5.3, sys/types and inttypes.h are conflicting.
for ac_header in sys/types.h sys/stat.h stdlib.h string.h memory.h strings.h \
		 inttypes.h stdint.h unistd.h
do :
 as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
ac_fn_c_check_header_compile "$LINENO" "$ac_header" "$as_ac_Header" "$ac_includes_default
"
if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
 cat >>confdefs.h <<_ACEOF
#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
_ACEOF
fi
done
The check for sys/random.h starts from line 7758, so sys/types.h is already (accidentally) included when checking it.
So, here's the fix.

I can conform that Chi Hsuan Yen's patch works for me.
I'm concerned that the build includes sys/random.h despite it not actually being needed to build python on mac os x (my worry is possible "shenanigans" by Apple in future versions of their headers) 
But if this patch makes sense to those who actually speak "./configure", I'm agnostic enough.

This is currently blocking the release of 3.5.3 rc1.

New changeset 9ab75789c554 by Benjamin Peterson in branch '3.5':
only include sys/random.h if it seems like it might have something useful (#29057)
https://hg.python.org/cpython/rev/9ab75789c554
New changeset 74eb71b91112 by Benjamin Peterson in branch '2.7':
only include sys/random.h if it seems like it might have something useful (#29057)
https://hg.python.org/cpython/rev/74eb71b91112
New changeset 5d0cb1fd79ea by Benjamin Peterson in branch '3.6':
merge 3.5 (#29057)
https://hg.python.org/cpython/rev/5d0cb1fd79ea
New changeset bb0d145b43a3 by Benjamin Peterson in branch 'default':
merge 3.6 (#29057)
https://hg.python.org/cpython/rev/bb0d145b43a3 

Can this be marked closed now?

I just did a quick build test of a few 3.5 configurations with various macOS releases and Benjamin's applied change seems to fix the previous build failures. No idea about OpenBSD.

I'm making an executive decision to not hold up the 3.5.3rc1 release for OpenBSD. Hopefully the OpenBSD folks can make sure it works for them before 3.5.3 final ships in two weeks.

This is still affecting me on 2.7, even with the new changes. 3.7 seems to be OK (I'm getting a different error on 3.7, but it seems unrelated to this.)
OS X 10.11.6.

I take it back... turns out I was building with the unsupported macports gcc.

Mr. Nasby, as long as you're in a test-reproducing mood, would you mind downloading the source to 3.5.3rc1 and confirming that it builds correctly for you? I'd appreciate it! (Not that I don't trust Ned et al, but independent confirmation always helps soothe these jangled nerves.)

I am encountering this problem on macOS 10.12.2, with Xcode 8.2.1 (latest).
I have tried building from the following cpython branches today (using the github fork):
2.7: 13a39142c047
In file included from ../../Python/random.c:7:
/usr/include/sys/random.h:37:32: error: unknown type name 'u_int'
void read_random(void* buffer, u_int numBytes);
3.5: 35334a4d41aa
3.6: 6bf563472ccd
Both 3.x branches report a different error:
../../Python/pytime.c:567:11: warning: implicit declaration of function 'clock_gettime' is invalid in C99 [-Wimplicit-function-declaration]
 err = clock_gettime(CLOCK_REALTIME, &ts);
 ^
../../Python/pytime.c:567:25: error: use of undeclared identifier 'CLOCK_REALTIME'
 err = clock_gettime(CLOCK_REALTIME, &ts);
 ^
../../Python/pytime.c:581:13: warning: implicit declaration of function 'clock_getres' is invalid in C99 [-Wimplicit-function-declaration]
 if (clock_getres(CLOCK_REALTIME, &res) == 0)
 ^
../../Python/pytime.c:581:26: error: use of undeclared identifier 'CLOCK_REALTIME'
 if (clock_getres(CLOCK_REALTIME, &res) == 0)
 ^

(I meant the github mirror: github.com/python/cpython)

George, did you do totally clean builds, including rerunning ./configure? If so, what ./configure and make commands did you use? Using the current hg repo, I don't see the failures you are seeing.

Still seeing this problem. Here was my exact process:
$ git clone git@github.com:python/cpython.git
$ cd cpython
$ git checkout 2.7
$ mkdir build
$ cd build
$ ../configure
$ make
In file included from ../Python/random.c:7:
/usr/include/sys/random.h:37:32: error: unknown type name 'u_int'

This is using the latest apple toolchain on latest macOS 10.12.2:
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i386-apple-darwin11.3.0

Sorry, George, but I'm unable to reproduce the failure you observe following your recipe. The only thing I can suggest off the top of my head is that you might have out-of-date system header files installed in /usr/include. Those files are installed with:
sudo xcode-select --install
They don't get installed or updated by just installing Xcode itself. See if that helps.

I reinstalled the command line tools by downloading from developer.apple.com/download/more and the problem went away. No idea how they broke; I had previously installed the same version. In any case, sorry for the noise.

Releasing 3.5.3 even though technically this is an open release blocker. IIUC the fix is checked in, and fixed the issue for OS X. We don't know whether or not it is also fixed on OpenBSD, because we don't know anybody running OpenBSD, and nobody contacted us regarding OpenBSD during the 3.5.3 RC period. Anyway I'm declaring victory and moving on. Maybe we can mark this bug closed?