OBJECT collections in CMake don't generate any artifacts so these
are safe to hoist out and define globally.
library OBJECT targets are just a list of filenames. It can be useful for
other projects to include lists of sources directly regardless of build mode
(shared, static, or library).
CMAKE_SOURCE_DIR is the top-level directory of a project, but if you include
this as a dependency, the file check locations won't exist at the top level
of any parent project.
CMAKE_CURRENT_SOURCE_DIR is the actual directory of the current project()
regardless of compile mode (standalone or included in another project).
- delete crypto.def and generate it from Symbols.list
- remove BIO_s_log since bss_log.c is not included on Windows
- add Windows specific symbols by crypto/crypto_win.list
- according to man.openbsd.org getentropy() is in unistd.h
- according to macOS sierra's man it's in sys/random.h
- since sys/random.h is does not exist for iOS and for linux, do
not attempt to include it, rather redeclare the prototype
- make sure that `./configure`:
- uses getentropy() on macOS sierra
- does not use getentropy() if compiling for 10.11
- does not use getentropy() if compiling for ios armv7
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
