This diff changes the logic by which configure detects getentropy() to
ensure that we don't use the system wide getentropy
- with macOS sierra if the deployment target is lower than sierra as
found by tor developers here
https://gitweb.torproject.org/tor.git/commit/?id=https://gitweb.torproject.org/tor.git/commit/?id=16fcbd21c963a9a65bf55024680c8323c8b7175d
- with iOS unconditionally because an app linking libressl compiled with
system wide getentropy has been rejected by the App store as I have
documented here
https://github.com/measurement-kit/measurement-kit/pull/994
I think something similar could also affect clock_gettime judging from
tor's patch, but this diff for now doesn't address that.
I do not have macOS < sierra, so I could only verify that configure was
not picking up system wide getentropy by compiling libressl using
export CFLAGS="-mmacosx-version-min=10.11"
As regards iOS, removing the check for getentropy and recompiling (thus
using libressl builtin getentropy()) was enough to have another iteration
of the app accepted. Otherwise testing should be possible with:
export LDFLAGS=-arch armv7 -miphoneos-version-min=7.1 -isysroot `xcrun --show-sdk-path --sdk iphoneos`
export CPPFLAGS=-arch armv7 -isysroot `xcrun --show-sdk-path --sdk iphoneos`
export CFLAGS=-arch armv7 -miphoneos-version-min=7.1 -isysroot `xcrun --show-sdk-path --sdk iphoneos`
Related ticket: https://github.com/libressl-portable/portable/issues/230
Solaris 11 recently introduced a builtin arc4random in libc which fails the tests in "make check". Found USE_BUILTIN_ARC4RANDOM, but could not get it to work. Apparently, there is a typo in the configure logic rendering USE_BUILTIN_ARC4RANDOM ineffective.
