Re: Windows port binaries

[Po Lu <luangruo@yahoo.com>]

Bruno Haible <bruno@clisp.org> writes:

> Corwin Brust wrote:
>> In case it helps others to assist with testing, for the moment I am
>> aggressively rebuilding the Windows port also, from (not quite every)
>> commit to emacs-29 or master, posting to:
>> 
>>   https://corwin.bru.st/emacs-29
>>   https://corwin.bru.st/emacs-30
>
> Thanks. I tried to use the
> https://corwin.bru.st/emacs-30/emacs-30-latest-no-deps.zip
> binary from today, but they don't work for me (on Windows 10), because
> they rely on two DLLs which are not contained in the 'bin' directory:
>   - libgmp-10.dll
>   - libwinpthread-1.dll
>
> Find below the output of "dumpbin.exe /imports emacs.exe".
>
> Additionally, I find it strange:
>
>   1) Why are the imports from libgmp all prefixed with '__'? That's
>      a bit unusual.

GMP prefers such a naming convention for their exported symbols.  These
symbols are defined to their programmer-facing names in gmp.h.

>   2) emacs/nt/mingw-cfg.site contains this comment:
>        # We don't want to check for these functions
>        # because they are implemented in libwinpthread.
>      corresponding to this ChangeLog entry:
>
>        2016-04-21  Fabrice Popineau  <fabrice.popineau@gmail.com>
>
>                Avoid run-time dependency on libwinpthread DLL on MS-Windows
>
>                * nt/mingw-cfg.site (ac_cv_search_clock_gettime)
>                (ac_cv_func_clock_gettime, ac_cv_func_clock_settime): Force to not
>                present, so that MinGW64 builds don't depend on libwinpthread.
>                (Bug#22959)
>
>      However, the binaries rely on nanosleep() from libwinpthread.
>      Is it intended or unintended?
>      If it is unintended, does it come from Gnulib? In this case, I'll gladly
>      help to do anything needed in Gnulib to help avoid this import.

I was under the impression that Emacs is supposed to use the nanosleep
from MinGW, so this should be investigated.