bug#22959: Emacs on Windows depends on libwinpthreads

[phillip.lord@russet.org.uk (Phillip Lord)]

Eli Zaretskii <eliz@gnu.org> writes:
>> Currently, building Emacs under msys2/ming-w64 produces a binary that
>> depends on libwinpthread.dll. The practical upshot of this is that after
>> building and installing Emacs according to the instructions, Emacs
>> cannot be launched from the Windows explorer -- it can be run from msys2
>> which has the path set up correctly. A binary release will, therefore, fail.
>> 
>> Using the dependency walker shows the dependency is directly from Emacs,
>> and it appears to have come from a change in ming-w64, as reported here.
>> 
>> https://sourceforge.net/p/mingw-w64/mailman/message/31213279/
>> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748353
>> 
>> This affects emacs-25, master and, indeed, emacs-24 built using the
>> current tool chain.
>
> If MinGW64 builds binaries that depend on libwinpthread DLL, then why
> isn't that DLL part of the MinGW64 GCC installation?  That sounds like
> a bug in MinGW64 packaging, or maybe your installation is somehow
> incomplete or misconfigured?

It is part of the distribution. The problem is generating a binary for
other people that they can use. If I install Emacs and then package that
location, the executable will not work.


> (This is the first time that a MinGW64 Emacs user complains about
> this, so I wonder how others solve this problem.)

The Emacs-W64 distribution which builds in ming-w64 just copies
libwinpthread-1.dll into the bin directory.

The other solution is

./configure CFLAGS=-static


> The fact that Emacs runs OK when launched from MSYS2 Bash suggests
> that the DLL exists, but is not on PATH.  Which might mean you need to
> change your system configuration to augment PATH.

Yes, that would work, but would be required on every machine that uses
Emacs.

>
> Or maybe you should use a different build of MinGW64 GCC?  The second
> bug report you quote seems to indicate that there's a build which uses
> Windows threads, so it doesn't depend on the pthread library.

It does seem to suggest that, although I cannot find how to use this
from any documentation I have found. I will investigate further.

> Sorry, I don't use MinGW64, so I cannot help you more.

Phil