bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems compiling 'getrandom' with MinGW


From: Bruno Haible
Subject: Re: Problems compiling 'getrandom' with MinGW
Date: Sun, 28 Jun 2020 21:32:47 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-179-generic; KDE/5.18.0; x86_64; ; )

Hi Eli,

> > > 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

This "subtlety" is *the* documented way to build a binary for a different
Windows version than the default for the tool set that you have installed.
Quoting:

  "The preprocessor macros WINVER and _WIN32_WINNT specify the minimum
   operating system version your code supports."

A web search for "windows compile vista" turns up this page among the
first 10 hits.

This convention is also supported by the mingw headers.

I don't see the point of not obeying this convention.

> What does Gnulib and its users
> gain by linking statically against the DLL?

1) Testability: With a static dependency, you notice immediately if a binary
is not working on the set of desired target platforms. With dynamic loading,
you have to exercise a particular functionality in order to notice it.

2) You will have noticed in the code that if linking directly with bcrypt.dll,
the code does not even attempt to invoke the other deprecated Microsoft DLL.

> 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?

Come on. I'm not telling the Emacs Windows porters to "jump through hoops".
I'm telling them to add "-D_WIN32_WINNT=_WIN32_WINNT_WINXP" to $CC or
$CPPFLAGS, if Windows XP is their minimum target Windows version.

> I was once told by RMS that GNU projects are
> supposed to support one another.

Sure. That's what I'm doing by replying to your mail within less than 2 hours
- interrupting my work on other GNU projects - and giving you an advice that
is consistent with the Microsoft documentation and the stackoverflow.com
know-how.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]