Can you please tell more about how this causes non-working code? MinGW64 defines EOPNOTSUPP to an arbitrary constant which (AFAICT) is never actually returned or used in the MS-Windows runtime. Their documentation, in https://docs.microsoft.com/en-us/cpp/c-runtime-library/errno-constants?view=msvc-170, says:

The following values are supported for compatibility with POSIX:

Which IME is a euphemism for "don't expect this to do anything real". So if I understand correctly what you say, this code cannot work at all on MS-Windows?

Maybe if I understood more why it won't work, I could suggest a better fix?

Failing that, I think the configure script should automatically disable that option if EOPNOTSUPP isn't defined, or maybe on MS-Windows in general.

Let me ask a more specific question, since you mentioned "support of detecting numbers of CPU and having more than 1 CPUs": can you point me to the code which detects the number of CPUs on MS-Windows systems, where I could learn how that code is affected by having EOPNOTSUPP defined? I will then hopefully understand better what you are saying, and either agree with you that this is unworkable on Windows, or propose a better solution.

In libgcrypt (1.10), we have a copy of the jitterentropy 3.3.0 from:
http://www.chronox.de/jent.html
or https://github.com/smuellerDD/jitterentropy-library

And we added our local changes to match use case for libgcrypt.

I might be wrong, but I think that jitterentropy is basically for native POSIX environment.

The particular code in question, where I concluded that it won't work on Windows is that: the function jent_notime_init in jitterentropy-timer.c which use EOPNOTSUPP. It uses jent_ncpu but it currently uses sysconf to get the information.

Because I don't have much knowledge for Windows, it is likely this analysis of mine may be wrong. I just suggested a possible workaround to build usable libgcrypt on your environment successfully/quickly.

Well, it's my pleasure to meet you again in the cyberspace, Eli. :-)

Yes, I see the problem:

static inline long jent_ncpu(void)
{
#ifdef _POSIX_SOURCE
	long ncpu = sysconf(_SC_NPROCESSORS_ONLN);

	if (ncpu == -1)
		return -errno;

	if (ncpu == 0)
		return -EFAULT;

	return ncpu;
#else
	return 1;
#endif
}

So yes, this always yields 1 on MS-Windows.
On Windows, there's a simple API to get the number of processors on the system: GetNativeSystemInfo. Would you like me to submit a patch that used that in jent_ncpu?

GetNativeSystemInfo. Would you like me to submit a patch that used that in jent_ncpu?

Yes, please.

Then, I'll incorporate changes to libgcrypt (along with EOPNOTSUPP).

In libgcrypt, we mix randomness from system (GcyptGenRandom on Windows) and one from jent. Please note that --disable-jent-support is generally acceptable (in most use cases), when porting it is difficult.

The attached patch implements getting the number of processors on MS-Windows.

I see in jitterentropy-base-user.h you also use the CPU cache size on GNU/Linux. Is it important to have that information on MS-Windows? If so, I can submit a patch for that as well: there's a native Windows API on newer Windows systems to get that info.

you also use the CPU cache size on GNU/Linux. Is it important to have that information on MS-Windows?

No, it's not important now (for GNU/Linux, either). In the past, we used the value to allocate more memory, so that it can result more memory access jitter. But these days, L2/L3 cache is getting larger, it's not practical to use larger memory than the cache size (as it has impact to memory resource).

We have upper limit for allocated memory size, that's JENT_MEMORY_SIZE == 128KB. <-- this is now usually (far) less than L2/L3 cache size.

Pushed the change to master.

Applied to 1.10.