Fixes one of the items in #923, namely the warnings of the form
'_putenv' redeclared without dllimport attribute:
previous dllimport ignored [-Wattributes]
This also cleans up the way we add CFLAGS, in particular flags enabling
warnings. Now we perform some more fine-grained checking for flag
support, which is not strictly necessary but the changes also help to
document autoconf.ac.
Valgrind is typically installed using brew on macOS. This commit
makes ./configure detect this case set the appropriate include
directory (in the same way as we already do for openssl and gmp).
Instead of supporting configuration of the field and scalar size independently,
both are now controlled by the availability of a 64x64->128 bit multiplication
(currently only through __int128). This is autodetected from the C code through
__SIZEOF_INT128__, but can be overridden using configure's
--with-test-override-wide-multiply, or by defining
USE_FORCE_WIDEMUL_{INT64,INT128} manually.
e7daa9b [build] Tweak JNI macro to warn instead of error for JNI not found. (Karl-Johan Alm)
5b22977 [build] Update ax_jni_include_dir.m4 macro to deal with recent versions of macOS (Karl-Johan Alm)
Pull request description:
Prior to this patch, this macro fails to find a working directory for the JNI headers, and results in compile failure when doing
```
./configure --enable-experimental --enable-module-ecdh --enable-jni
```
on more recent macOS versions. The relevant commit upstream is [here](http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=commit;h=ab23d25b1f1ae544fffdaa0a94a794798695c672) from the [GNU.org page for the macro](https://www.gnu.org/software/autoconf-archive/ax_jni_include_dir.html). The original (identical to the version in this commit) is [here](http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_jni_include_dir.m4).
The compile failure:
```Bash
$ make
gcc -I. -g -O2 -Wall -Wextra -Wno-unused-function -c src/gen_context.c -o gen_context.o
gcc gen_context.o -o gen_context
./gen_context
CC src/libsecp256k1_la-secp256k1.lo
CC src/java/libsecp256k1_jni_la-org_bitcoin_NativeSecp256k1.lo
In file included from src/java/org_bitcoin_NativeSecp256k1.c:4:
In file included from src/java/org_bitcoin_NativeSecp256k1.h:2:
/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Headers/jni.h:45:10: fatal error:
'jni_md.h' file not found
#include "jni_md.h"
^
1 error generated.
make: *** [src/java/libsecp256k1_jni_la-org_bitcoin_NativeSecp256k1.lo] Error 1
```
Tree-SHA512: 9a8305b3ed67eba0de728f91cf435857a676ba10507ab8481a3c03b50e1ce0469a3d79e751d0a697018789f21e2aa48b7eccca4d225520a3863fcf23f1fd487a
The only reason OpenSSL 1.1 was not supported was the removal of direct
access to r and s in ECDSA_SIG. This commit adds a simplified version of
ECDSA_SIG_get0 for < 1.1 that can be used like ECDSA_SIG_get0 in >= 1.1
OpenSSL 1.1 makes ECDSA_SIG opaque and our tests need access
inside this object.
The comparison tests against OpenSSL aren't important for most
users, but the build failing is...
Squashed and rebased. Thanks to @theuni and @faizkhan00 for doing
the majority of work here! Also thanks to @btchip for help with debugging
and review.
I Noticed this on OSX with clang, though it likely happens elsewhere as well.
The result is disabled x86_64 asm.
Due to missing escaping, this $0 was interpreted as the function name
SECP_64BIT_ASM_CHECK, causing the compile-check to be broken on some compilers.
The actual check looked like this:
int main()
{
uint64_t a = 11, tmp;
__asm__ __volatile__("movq SECP_64BIT_ASM_CHECKx100000000,%1; mulq %%rsi" : "+a"(a) : "S"(tmp) : "cc", "%rdx");
return 0;
}
It seems even more odd that it compiled anywhere.
This vastly shrinks the size of the context required for signing on devices with
memory-mapped Flash.
Tables are generated by the new gen_context tool into a header.
Tim Ruffing
Pieter Wuille
Dimitris Apostolou
Elichai Turkel
fanquake
Jonas Nick
Gregory Maxwell
Alexander Block
Karl-Johan Alm
Pieter Wuille
GreenAddress
Cory Fields
Thomas Daede
Luke Dashjr
kiwigb