Compiler switch -mlp64 (GCC) or +DD64(HP CC) gives build failure with
platform HP-UX other than IA-64.
This avoids build break on HP-UX with PA-RISC platform.
Suggested from Larkin Nickle (me <at> larbob org) by libressl ML.
The arpa/nameser.h, netinet/ip.h, and resolv.h headers are not crucial
to building LibreSSL. The netinet/ip.h header is used in nc(1) for
optional IPTOS_ features that can be ifdef'd on systems without support.
The endian.h header is the upcoming standard header and should be used
whenever available and correct. The machine/endian.h header is
non-standard and doesn't have to exist on POSIX systems.
Fix the check for getpagesize(3) not forward declaring the function,
such that CFLAGS with -Werror=implicit-function-declaration doesn't
cause the check to fail.
These variables were being ignored because libtool doesn't pass -static-libgcc to GCC.
If you want to link libgcc statically, currently the only way to achieve this is to
manually add -static-libgcc to CC variable. See:
http://www.mingw.org/wiki/HOWTO_Sneak_GCC_Switches_Past_Libtool
- 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
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.
