Alternative solutions welcome.

return 0? (aka, do nothing)
I assume we are already mixing /dev/urandom elsewhere though - if not, ACK

Alternative solutions welcome.

How about not using getentropy on Linux? It's a BSD compatibility function. The Really Good (TM) solution is using SYS_getrandom, but if that's not available, just fallback to using /dev/urandom directly.

I assume we are already mixing /dev/urandom elsewhere though.

No. getrandom / getentropy replace the need for /dev/urandom.

Just had a quick chat about this on IRC. I'll fix this up as discussed.

Huh? we should never be using getentropy() on Linux, that's why the getrandom() syscall is called directly. What is going wrong here exactly?

Edit: ok after discussion on IRC understand, getentropy is detected on newer versions of glibc, causing that to be used. That should be avoided, the SYS_getrandom path should always be used on Linux, getentropy is for BSD.

Updated as discussed with @sipa on IRC.

@laanwj: specifically, the problem is building against a newer glibc, and older linux kernel headers for compatibility. So getentropy() is defined, but the syscall isn't. That's what I ran into here.

Would you like to explicitly disable getentropy for linux on the build side as well?

@theuni This commit simplifies the fallback logic a bit: sipa@0abac37

Both this PR or just disabling getentropy on Linux are fine solutions to me.

Would you like to explicitly disable getentropy for linux on the build side as well?

I don't see why we'd need it. I made the syscall-based path for Linux to avoid having to rely on any function provided by glibc (e.g. to require a certain glibc version) for kernel randomness. But I don't care deeply, as long as it works...

utACK e596faf. Unclear from discussion above whether there is agreement to continue allowing fallback to getentropy on linux, though IMO it makes the code cleaner to fall straight through all the available calls like this PR does (despite the need for the weak symbol workaround).

sipa's simplification sipa@0abac37 also seems good.

@theuni can you comment on @sipa's implementation?

Looking at this again with fresh eyes, I think the most straightforward is to only enable getentropy for openbsd, where we know what it's doing:

#elif defined(HAVE_GETENTROPY) && defined(__OpenBSD__) 

Then we can drop all of the compat stuff. Sound reasonable?

Yes, sounds good to me.

Ok, closing this and opening a new PR as this no long has anything to do with back-compat.