Make sure that the opposite of no is indeed gmp.

Make bignum explicitely yes and remove install directive

I'm sorry, but I don't buy the finalization argument, mostly because it's not an argument. I've seen enough cultish behavior in this industry to know people will say you shouldn't do X or must do Y the Z way with absolutely no reason whatsoever and it often turns out to be a bad idea. If there is a reason to not do it, then people should be able to state it and we should be able to assert why it applies or not to our current situation. Every time someone brings up that this is the "the way" without providing a proper rationale, this is only a stronger reason to dismiss this concern.

Fix travis

Address comments

Update

Address comments

Remove leftover print

So I test with clang 8, clang 8 and gcc 9 and I cannot repro. This suggest that this is a problem with the CI and that it should be fixed there - or that there is something the CI is doing that we are not, in which case we also need to know.

Well, what's the log of the bitcoind process? Why did it exit?

This still doesn't say what the problem is.

Can you provide a reason in the description?

Why?

Remove unecesary include

There is still no finalizer for that class unless I messed it, which means context will be leaked when things are garbage collected.

If event needs ws2_32 on some plateform, then it needs it on some plateforms. This needs to be part of the fix.

Test plan is inadequate.

Event requires lib ws2_32 on windows

The test plan is inadequate.

This is obviously wrong. The fact that it happens to work doesn't make it right.

Theres also fixing cloneContext, which IMO should result in returning a new NativeSecp256k1 class with the cloned native lib context in, but i was hoping to fix that on another ticket.

Looks like there is some duplication with the test runner.

This is leaking. Note that it was already leaking, indeed, but because everything was static, the application would just leak one context and voila. Now it can leak n contexts, and this is bad. There is also a problem of error management when the context is created or used. This also is preexisting, but one can assume that creating one context at program startup is less likely to fail (for instance due to OOM) than when the java app is up and runnign and eating 16GB of RAM, like all self respecting java apps do.

Well then, if it is a build type, then it is a build type, no? Not an option.