bug#22959: Emacs on Windows depends on libwinpthreads

bug#22959: Emacs on Windows depends on libwinpthreads

[Phillip Lord]

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.

bug#22959: Emacs on Windows depends on libwinpthreads

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Date: Wed, 09 Mar 2016 14:52:18 +0000
> 
> 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?  (This is the first time that a MinGW64
Emacs user complains about this, so I wonder how others solve this
problem.)

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.

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.

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

bug#22959: Emacs on Windows depends on libwinpthreads

[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

bug#22959: Emacs on Windows depends on libwinpthreads

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: 22959@debbugs.gnu.org
> Date: Wed, 09 Mar 2016 16:32:44 +0000
> 
> > 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.

Ah, okay.  Then I think the only way of making distributable binaries
is to find a GCC distribution that doesn't infect programs it produces
with the libwinpthread dependency.

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

Someone who does that will have to provide the sources of that library
from the same location, or they will be in violation of the GPL.

> The other solution is
> 
> ./configure CFLAGS=-static

If that gives reasonable results, yes.  What problems, if any, does it
create?

bug#22959: Emacs on Windows depends on libwinpthreads

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: 22959@debbugs.gnu.org
>> Date: Wed, 09 Mar 2016 16:32:44 +0000
>> 
>> > 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.
>
> Ah, okay.  Then I think the only way of making distributable binaries
> is to find a GCC distribution that doesn't infect programs it produces
> with the libwinpthread dependency.

IIUC, I could cross-compile Emacs on debian, but I don't know if that
would solve the issue. The mingw mailing list suggests that it's not
possible using their tool chain.


>> > (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.
>
> Someone who does that will have to provide the sources of that library
> from the same location, or they will be in violation of the GPL.

Does it? libwinpthread isn't GPL. I would assume that it's a system
library so is not covered by Emacs' GPL either.


>> The other solution is
>> 
>> ./configure CFLAGS=-static
>
> If that gives reasonable results, yes.  What problems, if any, does it
> create?

Well, it works, which is a reasonable result.

Disadvantage? I guess, if it is dropped into an existing ming-w64
installation, then it will (effectively) duplicate the libwinpthread
binary that is there. More, it will not gain any updates to that
libwinpthread library. If Emacs is being used standalone on a system
with no other part of mingw/msys then these points are moot.

Phil

bug#22959: Emacs on Windows depends on libwinpthreads

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: 22959@debbugs.gnu.org
> Date: Wed, 09 Mar 2016 18:56:37 +0000
> 
> >> The other solution is
> >> 
> >> ./configure CFLAGS=-static
> >
> > If that gives reasonable results, yes.  What problems, if any, does it
> > create?
> 
> Well, it works, which is a reasonable result.
> 
> Disadvantage? I guess, if it is dropped into an existing ming-w64
> installation, then it will (effectively) duplicate the libwinpthread
> binary that is there. More, it will not gain any updates to that
> libwinpthread library. If Emacs is being used standalone on a system
> with no other part of mingw/msys then these points are moot.

If that's the only problem, then I'd say go for it.

bug#22959: Emacs on Windows depends on libwinpthreads

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

Hi,

At this point, when I build emacs for w64 using msys2,
emacs.exe depends on libwinpthread for only one symbol
which is clock_gettime().
This is called from lib/gettime.c:gettime().
It may be possible to remove this dependency for w64
and switch to gettimeofday(). No idea if we would lose
something in doing so.

There is another dependency which is libdbus.dll, which
is automatically found. I have no idea if dbus is useful
for w64/msys2.

I may add that a full blown emacs compiled with msys2
needs up to 57 dlls to run ( that is : all image formats dll,
gnutls, etc.) and this is what I copy in my emacs/bin directory.

Fabrice

[-- Attachment #2: Type: text/html, Size: 850 bytes --]

bug#22959: Emacs on Windows depends on libwinpthreads

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sat, 16 Apr 2016 23:48:35 +0200
> 
> At this point, when I build emacs for w64 using msys2,
> emacs.exe depends on libwinpthread for only one symbol
> which is clock_gettime().
> This is called from lib/gettime.c:gettime().

This is not supposed to happen.  I don't see this on my system.

There's some factor at work here that I cannot figure out: the
configure-time test for clock_gettime doesn't try to look for that
function in the pthreads library, it only tries the "normal" link
without any extra libraries, and if that fails, tries 2 extra
libraries: librt and libposix4, none of which I'd expect to see on
MS-Windows in a MinGW installation.

It could be something peculiar to MinGW64/MSYS2 build.  Are you sure
libwinpthread dependency is not a requirement of the MinGW64 GCC port?

So please look in config.log, and tell how did pthreads get into this
test.

> It may be possible to remove this dependency for w64
> and switch to gettimeofday(). No idea if we would lose 
> something in doing so.

Probably nothing at all, as the 32-build AFAIK doesn't depend on
libwinpthread (at least mine doesn't).

> There is another dependency which is libdbus.dll, which
> is automatically found. I have no idea if dbus is useful
> for w64/msys2.

If you don't wand D-Bus, you can configure with --without-dbus.

> I may add that a full blown emacs compiled with msys2
> needs up to 57 dlls to run ( that is : all image formats dll,
> gnutls, etc.) and this is what I copy in my emacs/bin directory.

57 DLLs sounds excessive.  I counted the ones I think Emacs uses on my
system, and only got as far as 32.  Can you show a list of those 57
libraries?

bug#22959: Emacs on Windows depends on libwinpthreads

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 5389 bytes --]

2016-04-17 16:37 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Sat, 16 Apr 2016 23:48:35 +0200
> >
> > At this point, when I build emacs for w64 using msys2,
> > emacs.exe depends on libwinpthread for only one symbol
> > which is clock_gettime().
> > This is called from lib/gettime.c:gettime().
>
> This is not supposed to happen.  I don't see this on my system.
>
> There's some factor at work here that I cannot figure out: the
> configure-time test for clock_gettime doesn't try to look for that
> function in the pthreads library, it only tries the "normal" link
> without any extra libraries, and if that fails, tries 2 extra
> libraries: librt and libposix4, none of which I'd expect to see on
> MS-Windows in a MinGW installation.
>
> It could be something peculiar to MinGW64/MSYS2 build.  Are you sure
> libwinpthread dependency is not a requirement of the MinGW64 GCC port?
>
> So please look in config.log, and tell how did pthreads get into this
> test.


From config.log:

configure:24643: checking for library containing clock_gettime
configure:24674: gcc -I ../emacs/nt/inc -o conftest.exe -I/mingw64/include
-fomit-frame-pointer -O3 -g0 -mtune=corei7 -mtune=generic
 -I/mingw64/include -L/mingw64/lib conftest.c   >&5
configure:24674: $? = 0
configure:24691: result: none required
configure:24703: checking for clock_gettime
configure:24703: gcc -I ../emacs/nt/inc -o conftest.exe -I/mingw64/include
-fomit-frame-pointer -O3 -g0 -mtune=corei7 -mtune=generic
 -I/mingw64/include -L/mingw64/lib conftest.c   >&5
configure:24703: $? = 0
configure:24703: result: yes
configure:24703: checking for clock_settime
configure:24703: gcc -I ../emacs/nt/inc -o conftest.exe -I/mingw64/include
-fomit-frame-pointer -O3 -g0 -mtune=corei7 -mtune=generic
 -I/mingw64/include -L/mingw64/lib conftest.c   >&5
configure:24703: $? = 0
configure:24703: result: yes

Testing with a very short C file, it seems that libwinpthread-1.dll is
linked in by default and may be gets removed by the linker if no symbol is
referenced. I have asked for clarifications
on the msys2 list.

Anyway, I am afraid that some 3rd party libraries would require it anyway.
For example, --with-rsvg triggers the -pthread compile flag:

config.status:S["RSVG_CFLAGS"]="-pthread -mms-bitfields
-I/mingw64/include/librsvg-2.0 -I/mingw64/include/gdk-pixbuf-2.0
-I/mingw64/include/libpng16 -I/mingw64/include/cairo -I/min"\

>
> > I may add that a full blown emacs compiled with msys2
> > needs up to 57 dlls to run ( that is : all image formats dll,
> > gnutls, etc.) and this is what I copy in my emacs/bin directory.
>
> 57 DLLs sounds excessive.  I counted the ones I think Emacs uses on my
> system, and only got as far as 32.  Can you show a list of those 57
> libraries?
>

configure command is:

  $ ../emacs/configure --prefix=/c/Local/Emacs-25
--libexecdir=/c/Local/Emacs-25/bin --datarootdir=/c/Local/Emacs-25
--localstatedir=/c/Local/Emacs-25 --sysconfdir=/c/Local/Emacs-25/etc
--with-jpeg --with-xpm --with-png --with-tiff --with-rsvg --with-xml2
--with-gnutls --with-imagemagick --enable-checking=no

and the dll list is:

/c/Local/Emacs/bin/libasprintf-0.dll*
 /c/Local/Emacs/bin/libgmodule-2.0-0.dll*
/c/Local/Emacs/bin/libMagickWand-6.Q16HDRI-2.dll*
/c/Local/Emacs/bin/libbz2-1.dll*
/c/Local/Emacs/bin/libgmp-10.dll*
 /c/Local/Emacs/bin/libnettle-6-1.dll*
/c/Local/Emacs/bin/libcairo-2.dll*
/c/Local/Emacs/bin/libgnutls-30.dll*
/c/Local/Emacs/bin/libp11-kit-0.dll*
/c/Local/Emacs/bin/libcairo-gobject-2.dll*
/c/Local/Emacs/bin/libgnutlsxx-28.dll*
/c/Local/Emacs/bin/libpango-1.0-0.dll*
/c/Local/Emacs/bin/libcairo-script-interpreter-2.dll*
 /c/Local/Emacs/bin/libgobject-2.0-0.dll*
/c/Local/Emacs/bin/libpangocairo-1.0-0.dll*
/c/Local/Emacs/bin/libcharset-1.dll*
/c/Local/Emacs/bin/libgomp-1.dll*
 /c/Local/Emacs/bin/libpangoft2-1.0-0.dll*
/c/Local/Emacs/bin/libcroco-0.6-3.dll*
/c/Local/Emacs/bin/libgraphite2.dll*
/c/Local/Emacs/bin/libpangowin32-1.0-0.dll*
/c/Local/Emacs/bin/libdbus-1-3.dll*
 /c/Local/Emacs/bin/libgthread-2.0-0.dll*
/c/Local/Emacs/bin/libpcre-1.dll*
/c/Local/Emacs/bin/libexpat-1.dll*
/c/Local/Emacs/bin/libharfbuzz-0.dll*
 /c/Local/Emacs/bin/libpixman-1-0.dll*
/c/Local/Emacs/bin/libffi-6.dll*
/c/Local/Emacs/bin/libhogweed-4-1.dll*
/c/Local/Emacs/bin/libpng16-16.dll*
/c/Local/Emacs/bin/libfftw3-3.dll*
/c/Local/Emacs/bin/libiconv-2.dll*
/c/Local/Emacs/bin/librsvg-2-2.dll*
/c/Local/Emacs/bin/libfontconfig-1.dll*
 /c/Local/Emacs/bin/libidn-11.dll*
 /c/Local/Emacs/bin/libstdc++-6.dll*
/c/Local/Emacs/bin/libfreetype-6.dll*
 /c/Local/Emacs/bin/libintl-8.dll*
 /c/Local/Emacs/bin/libtasn1-6.dll*
/c/Local/Emacs/bin/libgcc_s_seh-1.dll*
/c/Local/Emacs/bin/libjpeg-8.dll*
 /c/Local/Emacs/bin/libtiff-5.dll*
/c/Local/Emacs/bin/libgdk_pixbuf-2.0-0.dll*
 /c/Local/Emacs/bin/liblcms2-2.dll*
/c/Local/Emacs/bin/libtiffxx-5.dll*
/c/Local/Emacs/bin/libgettextpo-0.dll*
/c/Local/Emacs/bin/liblqr-1-0.dll*
/c/Local/Emacs/bin/libwinpthread-1.dll*
/c/Local/Emacs/bin/libgif-7.dll*
/c/Local/Emacs/bin/libltdl-7.dll*
 /c/Local/Emacs/bin/libxml2-2.dll*
/c/Local/Emacs/bin/libgio-2.0-0.dll*
/c/Local/Emacs/bin/liblzma-5.dll*
 /c/Local/Emacs/bin/libXpm-noX4.dll*
/c/Local/Emacs/bin/libglib-2.0-0.dll*
 /c/Local/Emacs/bin/libMagickCore-6.Q16HDRI-2.dll*
 /c/Local/Emacs/bin/zlib1.dll*

GnuTLS, ImageMagick and RSVG add quite many.

Fabrice

[-- Attachment #2: Type: text/html, Size: 7776 bytes --]

bug#22959: Emacs on Windows depends on libwinpthreads

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sun, 17 Apr 2016 17:25:23 +0200
> Cc: 22959@debbugs.gnu.org
> 
> >From config.log:
> 
> configure:24643: checking for library containing clock_gettime
> configure:24674: gcc -I ../emacs/nt/inc -o conftest.exe -I/mingw64/include
> -fomit-frame-pointer -O3 -g0 -mtune=corei7 -mtune=generic
>  -I/mingw64/include -L/mingw64/lib conftest.c   >&5
> configure:24674: $? = 0
> configure:24691: result: none required
> configure:24703: checking for clock_gettime
> configure:24703: gcc -I ../emacs/nt/inc -o conftest.exe -I/mingw64/include
> -fomit-frame-pointer -O3 -g0 -mtune=corei7 -mtune=generic
>  -I/mingw64/include -L/mingw64/lib conftest.c   >&5
> configure:24703: $? = 0
> configure:24703: result: yes
> configure:24703: checking for clock_settime
> configure:24703: gcc -I ../emacs/nt/inc -o conftest.exe -I/mingw64/include
> -fomit-frame-pointer -O3 -g0 -mtune=corei7 -mtune=generic
>  -I/mingw64/include -L/mingw64/lib conftest.c   >&5
> configure:24703: $? = 0
> configure:24703: result: yes
> 
> Testing with a very short C file, it seems that libwinpthread-1.dll is
> linked in by default and may be gets removed by the linker if no symbol is
> referenced.

So this is the reason for what you see: evidently, MinGW64 considers
libwinpthread DLL a necessary part of a MinGW64 linking.

We can easily prevent Emacs (in nt/mingw-cfg.site) from pulling
clock_gettime from libwinpthread, if we decide to do that.  But since
MinGW64 programs are evidently supposed to depend on that library, I
question the need for exempting just Emacs from this rule.

> I have asked for clarifications on the msys2 list.

I'm not sure they are the right crowd, it could be MinGW64 developers,
like Kai Tietz.

> Anyway, I am afraid that some 3rd party libraries would require it anyway.
> For example, --with-rsvg triggers the -pthread compile flag:
> 
> config.status:S["RSVG_CFLAGS"]="-pthread -mms-bitfields
> -I/mingw64/include/librsvg-2.0 -I/mingw64/include/gdk-pixbuf-2.0
> -I/mingw64/include/libpng16 -I/mingw64/include/cairo -I/min"\

That's not the same: the librsvg dependency is not a static one,
i.e. Emacs will start up even if libwinpthread is not available, it
just won't be able to display SVG images.  By contrast, the dependency
you are talking about is _static_, recorded at link time; Emacs will
refuse to start if the DLL is not present.

> and the dll list is:
> 
> /c/Local/Emacs/bin/libasprintf-0.dll*

Shouldn't be needed.

> /c/Local/Emacs/bin/libp11-kit-0.dll*

You should tell whoever build that GnuTLS to omit libp11-kit, it's
generally useless on Windows, certainly with Emacs.

> /c/Local/Emacs/bin/libgnutlsxx-28.dll*

Shouldn't be required, as long as Emacs is not a C++ program.

> /c/Local/Emacs/bin/libcharset-1.dll*

Shouldn't be required.

>  /c/Local/Emacs/bin/libpangoft2-1.0-0.dll*
> /c/Local/Emacs/bin/libgraphite2.dll*
> /c/Local/Emacs/bin/libfontconfig-1.dll*
> /c/Local/Emacs/bin/libfreetype-6.dll*

Whoever built Cairo didn't take care of disabling features unneeded on
Windows for librsvg.  The result is a very fat build of Cairo, for no
good reason.

> /c/Local/Emacs/bin/libpcre-1.dll*
> /c/Local/Emacs/bin/libexpat-1.dll*
> /c/Local/Emacs/bin/libharfbuzz-0.dll*

Are these also from librsvg dependencies?  If so, they are just
ballast, AFAIK.

> /c/Local/Emacs/bin/libfftw3-3.dll*

Which library needs this one?

>  /c/Local/Emacs/bin/libidn-11.dll*

Which library needs this one?

>  /c/Local/Emacs/bin/libstdc++-6.dll*

??? Why?  Emacs is not a C++ program.  In any case, using
"-static-libstdc++" should fix this, I think.

> /c/Local/Emacs/bin/libgcc_s_seh-1.dll*

Use -static-libgcc (and ask library maintainers to avoid this
dependency).

>  /c/Local/Emacs/bin/liblcms2-2.dll*

Which library needs this?

> /c/Local/Emacs/bin/libtiffxx-5.dll*

This is for C++ program, AFAIK.

> /c/Local/Emacs/bin/libgettextpo-0.dll*

Shouldn't be needed.

> /c/Local/Emacs/bin/liblqr-1-0.dll*

What is this library?

> /c/Local/Emacs/bin/libltdl-7.dll*

Which library needs this one?

bug#22959: Emacs on Windows depends on libwinpthreads

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]

I know you have been doing an amazing job at providing carefully configured
binary packages
for MinGW, but the situation is little bit more messy with MSys2/MingW64.
And I don't have time
to go the same way you did.

Let's do some cleaning then.


> > and the dll list is:
> >
> > /c/Local/Emacs/bin/libasprintf-0.dll*
>
> Shouldn't be needed.
>

Agreed, after checking.


>
> > /c/Local/Emacs/bin/libp11-kit-0.dll*
>
> You should tell whoever build that GnuTLS to omit libp11-kit, it's
> generally useless on Windows, certainly with Emacs.


Ok.


>
>
> /c/Local/Emacs/bin/libgnutlsxx-28.dll*
>
> Shouldn't be required, as long as Emacs is not a C++ program.
>

Agreed.

> /c/Local/Emacs/bin/libcharset-1.dll*
>
>
Agreed


> Shouldn't be required.
>
> >  /c/Local/Emacs/bin/libpangoft2-1.0-0.dll*
> > /c/Local/Emacs/bin/libgraphite2.dll*
> > /c/Local/Emacs/bin/libfontconfig-1.dll*
> > /c/Local/Emacs/bin/libfreetype-6.dll*
>
> Whoever built Cairo didn't take care of disabling features unneeded on
> Windows for librsvg.  The result is a very fat build of Cairo, for no
> good reason.
>

I have no insight on this. I think cairo is built independently

>
> > /c/Local/Emacs/bin/libpcre-1.dll*
>

is required by glib, itself required by cairo-gobject, croco, gdk_pixbuf,
gio, gmodule, gobject.



> > /c/Local/Emacs/bin/libexpat-1.dll*
>

Required by fontconfig.


> > /c/Local/Emacs/bin/libharfbuzz-0.dll*
>

Is required by libfreetype-6.dll
Which itself is required by libcairo-2.dll


>
> Are these also from librsvg dependencies?  If so, they are just
> ballast, AFAIK.
>
> > /c/Local/Emacs/bin/libfftw3-3.dll*
>
> Which library needs this one?
>
> MagickCore


> >  /c/Local/Emacs/bin/libidn-11.dll*
>
> Which library needs this one?
>
> GnuTLS


> >  /c/Local/Emacs/bin/libstdc++-6.dll*
>
>
Required by graphite


> > /c/Local/Emacs/bin/libgcc_s_seh-1.dll*
>
> Is required by libcairo-2.dll and its dependencies : libfontconfig-1.dll,
libpixman-1-0.dll



> >  /c/Local/Emacs/bin/liblcms2-2.dll*
>
> Which library needs this?
>

MagickCore


> > /c/Local/Emacs/bin/libtiffxx-5.dll*
>
> This is for C++ program, AFAIK.
>
> Agreed, removed.


> > /c/Local/Emacs/bin/libgettextpo-0.dll*
>
> Shouldn't be needed.
>
> Agreed, removed.


> > /c/Local/Emacs/bin/liblqr-1-0.dll*
>
> What is this library?
>
>
MagickCore


> > /c/Local/Emacs/bin/libltdl-7.dll*
>
> Which library needs this one?
>

MagickCore

Fabrice

[-- Attachment #2: Type: text/html, Size: 5580 bytes --]

bug#22959: Emacs on Windows depends on libwinpthreads

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sun, 17 Apr 2016 21:31:31 +0200
> Cc: 22959@debbugs.gnu.org
> 
> I know you have been doing an amazing job at providing carefully configured
> binary packages
> for MinGW, but the situation is little bit more messy with MSys2/MingW64.
> And I don't have time
> to go the same way you did.
> 
> Let's do some cleaning then.

OK.  Do we still have any problems left in this bug report?  Or can we
close it?

bug#22959: Emacs on Windows depends on libwinpthreads

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

2016-04-18 20:58 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Sun, 17 Apr 2016 21:31:31 +0200
> > Cc: 22959@debbugs.gnu.org
> >
> > I know you have been doing an amazing job at providing carefully
> configured
> > binary packages
> > for MinGW, but the situation is little bit more messy with MSys2/MingW64.
> > And I don't have time
> > to go the same way you did.
> >
> > Let's do some cleaning then.
>
> OK.  Do we still have any problems left in this bug report?  Or can we
> close it?
>

You can close it. The dependency towards libwinpthread is removed with the
small patch
to mingw-cfg.site .

Fabrice

[-- Attachment #2: Type: text/html, Size: 1290 bytes --]

bug#22959: Emacs on Windows depends on libwinpthreads

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Mon, 18 Apr 2016 21:50:44 +0200
> Cc: 22959@debbugs.gnu.org
> 
>  OK. Do we still have any problems left in this bug report? Or can we
>  close it?
> 
> You can close it. The dependency towards libwinpthread is removed with the small patch 
> to mingw-cfg.site .

I pushed that patch to master, and closing.

Thanks.

bug#22959: Emacs on Windows depends on libwinpthreads

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Fabrice Popineau <fabrice.popineau@gmail.com>
>> Date: Sat, 16 Apr 2016 23:48:35 +0200
>> 
>> At this point, when I build emacs for w64 using msys2,
>> emacs.exe depends on libwinpthread for only one symbol
>> which is clock_gettime().
>> This is called from lib/gettime.c:gettime().
>
> This is not supposed to happen.  I don't see this on my system.
>
> There's some factor at work here that I cannot figure out: the
> configure-time test for clock_gettime doesn't try to look for that
> function in the pthreads library, it only tries the "normal" link
> without any extra libraries, and if that fails, tries 2 extra
> libraries: librt and libposix4, none of which I'd expect to see on
> MS-Windows in a MinGW installation.


I did get the same thing at one point.


> It could be something peculiar to MinGW64/MSYS2 build.  Are you sure
> libwinpthread dependency is not a requirement of the MinGW64 GCC port?

This was the cause of the problem for me.

>
> So please look in config.log, and tell how did pthreads get into this
> test.
>
>> It may be possible to remove this dependency for w64
>> and switch to gettimeofday(). No idea if we would lose 
>> something in doing so.
>
> Probably nothing at all, as the 32-build AFAIK doesn't depend on
> libwinpthread (at least mine doesn't).


And this, also stemmed from msys2 rather than anything different in
Emacs.

Phil

bug#22959: Emacs on Windows depends on libwinpthreads

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

2016-04-18 15:06 GMT+02:00 Phillip Lord <phillip.lord@russet.org.uk>:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> >> Date: Sat, 16 Apr 2016 23:48:35 +0200
> >>
> >> At this point, when I build emacs for w64 using msys2,
> >> emacs.exe depends on libwinpthread for only one symbol
> >> which is clock_gettime().
> >> This is called from lib/gettime.c:gettime().
> >
> > This is not supposed to happen.  I don't see this on my system.
> >
> > There's some factor at work here that I cannot figure out: the
> > configure-time test for clock_gettime doesn't try to look for that
> > function in the pthreads library, it only tries the "normal" link
> > without any extra libraries, and if that fails, tries 2 extra
> > libraries: librt and libposix4, none of which I'd expect to see on
> > MS-Windows in a MinGW installation.
>
>
> I did get the same thing at one point.
>
>
> > It could be something peculiar to MinGW64/MSYS2 build.  Are you sure
> > libwinpthread dependency is not a requirement of the MinGW64 GCC port?
>
> This was the cause of the problem for me.
>
>
Add this:

diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
index 05034fe..0063c2b 100644
--- a/nt/mingw-cfg.site
+++ b/nt/mingw-cfg.site
@@ -40,6 +40,12 @@ gl_cv_sys_struct_timespec_in_pthread_h=no
 # Or at all...
 ac_cv_header_pthread_h=no

+# We don't want to check for these functions
+# because they are implemented in libwinpthread.
+ac_cv_search_clock_gettime="none required"
+ac_cv_func_clock_gettime=no
+ac_cv_func_clock_settime=no
+
 # ACL functions are implemented in w32.c
 ac_cv_search_acl_get_file="none required"
 ac_cv_func_acl_get_file=yes

And the dependency towards libwinpthread is gone for MinGW64.

Fabrice

[-- Attachment #2: Type: text/html, Size: 2776 bytes --]

bug#22959: Emacs on Windows depends on libwinpthreads

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Mon, 18 Apr 2016 15:41:59 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, 22959@debbugs.gnu.org
> 
> Add this:
> 
> diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
> index 05034fe..0063c2b 100644
> --- a/nt/mingw-cfg.site
> +++ b/nt/mingw-cfg.site
> @@ -40,6 +40,12 @@ gl_cv_sys_struct_timespec_in_pthread_h=no
> # Or at all...
> ac_cv_header_pthread_h=no
> +# We don't want to check for these functions
> +# because they are implemented in libwinpthread.
> +ac_cv_search_clock_gettime="none required"
> +ac_cv_func_clock_gettime=no
> +ac_cv_func_clock_settime=no
> +
> # ACL functions are implemented in w32.c
> ac_cv_search_acl_get_file="none required"
> ac_cv_func_acl_get_file=yes
> 
> And the dependency towards libwinpthread is gone for MinGW64.

I'm okay with pushing this to master.

bug#22959: Emacs on Windows depends on libwinpthreads

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

2016-04-18 21:02 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Mon, 18 Apr 2016 15:41:59 +0200
> > Cc: Eli Zaretskii <eliz@gnu.org>, 22959@debbugs.gnu.org
> >
> > Add this:
> >
> > diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
> > index 05034fe..0063c2b 100644
> > --- a/nt/mingw-cfg.site
> > +++ b/nt/mingw-cfg.site
> > @@ -40,6 +40,12 @@ gl_cv_sys_struct_timespec_in_pthread_h=no
> > # Or at all...
> > ac_cv_header_pthread_h=no
> > +# We don't want to check for these functions
> > +# because they are implemented in libwinpthread.
> > +ac_cv_search_clock_gettime="none required"
> > +ac_cv_func_clock_gettime=no
> > +ac_cv_func_clock_settime=no
> > +
> > # ACL functions are implemented in w32.c
> > ac_cv_search_acl_get_file="none required"
> > ac_cv_func_acl_get_file=yes
> >
> > And the dependency towards libwinpthread is gone for MinGW64.
>
> I'm okay with pushing this to master.
>

BTW, libwinpthread _is not_ GPL.
Sources can be found here
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-libraries/winpthreads/
You only need to redistribute the COPYING file.

Fabrice

[-- Attachment #2: Type: text/html, Size: 2154 bytes --]