Re: Problems compiling 'getrandom' with MinGW

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Sun, 28 Jun 2020 19:19:10 +0200
> 
> > 1. It assumes that the header bcrypt.h is always available.  This is
> > true for MinGW64, but not for mingw.org's MinGW.  A proposed patch to
> > allow the code be compiled without bcrypt.h is below
> 
> Thanks for the report and draft patch. I'm applying the patch below.

Thanks.

> My patch tests for the presence of <bcrypt.h>. _WIN32_WINNT >= 0x0600
> does not guarantee that <bcrypt.h> is present, because someone might,
> on a Windows XP machine, compile with -D_WIN32_WINNT=_WIN32_WINNT_WIN7.

I'm okay with testing for bcrypt.h's presence, of course.

> > 2. It causes the calling program to be linked against bcrypt.dll if
> > that library is available at build time.
> 
> No, it links the program against bcrypt.dll if you are compiling with
> a _WIN32_WINNT value >= _WIN32_WINNT_WIN7 - consistently with
> <https://docs.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom>
> and
> <https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt>.

Yes.  And that's the problem I was talking about: if some header sets
_WIN32_WINNT to such a value, for whatever reason, the program becomes
dependent on bcrypt.dll.  I very much doubt that people who do that,
or inherit this setting from someone else (perhaps the default of the
system headers) will be aware of this subtlety.

I'm asking why have that subtlety, when code to load the DLL at run
time already exists and is tested.  What does Gnulib and its users
gain by linking statically against the DLL?

> > Since the code to dynamically load bcrypt.dll is already in
> > getrandom.c, I suggest to leave only it, and remove the
> > possibility of linking against the DLL
> 
> Declined. The code is optimal for both the future and the past versions
> of Windows. Your proposal would make it less optimal for all versions
> starting with Windows 7.

Less optimal in what sense, exactly?

And what about being kind to a fellow GNU project, in this case Emacs?
Why should Emacs jump through hoops to make sure the Emacs binary on
Windows can be installed on any Windows version, regardless of how and
where it was built?  I was once told by RMS that GNU projects are
supposed to support one another.

I urge you to please reconsider.