Check for declaration of getentropy

[SamB]

This helps on Termux running on versions of Android that have getentropy in libc, but targetting an API level before getentropy was added (as Termux clang does by default).

[SamB]

Oh, this needs configure regenerated, does CI do anything about that or does that need to be done in the PR branch?

I suspect doing this under Termux may be suboptimal as it does not follow the FHS, but I could do it later on my computer.

[SamB]

Oh, looking at HACKING.adoc, it seems I am meant to update configure in my changes, converted to draft until I get a chance to hop on my computer and do that.

[shindere]

@SamB thank you for the PR! Yeah, sorry for the burden. Basically what you need to do is to run `autogen` and commit the configure file as updated by this script.

[shindere]

A question in addition to my previous comments: Your code replaces the call to the `AC_CHECK_FUNC` macro by a call to `AC_CHECK_DECL`. My understanding is that, if one is not cross-compiling, then this change slightly weakens the test as it only checks whether the function's declaration exists, whereas `AC_CHECK_FUNC` was also doing a linking test. I am wondering whether it wouldn't be possible and better to try and get best of both words: keeping the former test when not cross-compiling and falling back to your test when cross-compiling. I realize this is not how things are done elsewhere for the moment, but I am still sharing the idea so that we can start from somewhere. Cc the experts, @dra27, @MisterDA, @shym

[MisterDA]

I think you need both.
The definition of the function is guarded by a macro whose value is the current API level (aka minSdkVersion) The macro is set by Clang with its --target flag, with a possible value being aarch64-linux-android27.
I think I remember that the configure test was linking with the most recent libc on Android, so the linking test was succeeding, but the declaration was hidden so the compilation of the C file was failing.

[dra27]

There’s a number of things which are confusing me here. getentropy was only standardised in Issue 8, so the test for the declaration is likely to remain tricky for a while.

If configure wasn’t originally being regenerated, can I just double-check how this has been being tested?

For the original Android part of the problem, what changes later in the build system to allow this to work? i.e. I’m not yet clear what the connection is between what is failing in the check here (which sounds like a missing CFLAGS entry?) but then why it’s the build doesn’t subsequently have the same problem?