strange ezwinports issue

strange ezwinports issue

[Sivaram Neelakantan]

I've been using Eli's ezwinports binaries for Emacs 24.4 needed work.
I recently downloaded all the latest binaries and renamed the old
ezwinports as -old and the downloaded one as ezwinports.

Other than the folder renaming, nothing was changed but now I get
messages that it can't find any of the DLLs from zlib1 to the
libgnutls-28 one. Switching folder names again brings back the right
behaviour.  I did a folder comparision and other than files being
refreshed or a newer version with the same name, nothing seems to be
different in each of the folders.

I don't get any of the following messages when I used the latest set
of ezwinports.  BTW, I use cygwin  only for the certs and my
PATH has ezwinports/bin before the cygwin path

--8<---------------cut here---------------start------------->8---
gnutls.c: [1] (Emacs) GnuTLS library loaded: libgnutls-28.dll
gnutls.c: [1] (Emacs) allocating credentials
gnutls.c: [1] (Emacs) setting the trustfile:  c:/cygwin/usr/ssl/certs/ca-bundle.trust.crt
gnutls.c: [1] (Emacs) setting the trustfile:  c:/cygwin/usr/ssl/certs/ca-bundle.crt
gnutls.c: [1] (Emacs) gnutls callbacks
gnutls.c: [1] (Emacs) gnutls_init
gnutls.c: [1] (Emacs) got non-default priority string: NORMAL
gnutls.c: [1] (Emacs) setting the priority string
--8<---------------cut here---------------end--------------->8---

I don't get any of the above messages with the newer downloaded
 ezwinports gnutls and other binaries
 
 sivaram
 -- 

Re: strange ezwinports issue

[Eli Zaretskii]

> From: Sivaram Neelakantan <nsivaram.net@gmail.com>
> Date: Mon, 07 Sep 2015 23:08:20 +0530
> 
> I've been using Eli's ezwinports binaries for Emacs 24.4 needed work.
> I recently downloaded all the latest binaries and renamed the old
> ezwinports as -old and the downloaded one as ezwinports.
> 
> Other than the folder renaming, nothing was changed but now I get
> messages that it can't find any of the DLLs from zlib1 to the
> libgnutls-28 one. Switching folder names again brings back the right
> behaviour.  I did a folder comparision and other than files being
> refreshed or a newer version with the same name, nothing seems to be
> different in each of the folders.
> 
> I don't get any of the following messages when I used the latest set
> of ezwinports.  BTW, I use cygwin  only for the certs and my
> PATH has ezwinports/bin before the cygwin path

Does the problem go away if you put all of the ezwinports DLLs in the
same directory where you have emacs.exe?

Re: strange ezwinports issue

[Sivaram Neelakantan]

On Mon, Sep 07 2015,Eli Zaretskii wrote:

>> From: Sivaram Neelakantan <nsivaram.net@gmail.com>

[snipped 16 lines]

>
> Does the problem go away if you put all of the ezwinports DLLs in the
> same directory where you have emacs.exe?

Yes, it does.  Thanks for the fix.  What changed that necessitates
this kind of fix?


 sivaram
 -- 

Re: strange ezwinports issue

[Eli Zaretskii]

> From: Sivaram Neelakantan <nsivaram.net@gmail.com>
> Date: Tue, 08 Sep 2015 08:32:18 +0530
> 
> On Mon, Sep 07 2015,Eli Zaretskii wrote:
> 
> > Does the problem go away if you put all of the ezwinports DLLs in the
> > same directory where you have emacs.exe?
> 
> Yes, it does.  Thanks for the fix.  What changed that necessitates
> this kind of fix?

There was no change that necessitated this.  What this experiment
means is that you have a small "DLL hell" on your hands: you have an
incompatible copy of some DLL that is used by some of the ezwinports
that lives in some other directory which is closer to the beginning of
your PATH than the ezwinports' bin/ directory.  So when Emacs loads,
say, libgnutls-28.dll, and looks for its dependency DLLs, it finds
that incompatible DLL first, tries to load it, which fails (due to
whatever makes it incompatible), and then the load of libgnutls-28.dll
fails because of that.

When a Windows program needs to load a DLL, it always looks first in
the directory where that program's .exe file lives, so copying the
DLLs there "solved" that problem for you.

I suggest to invoke the dependency walker
(http://www.dependencywalker.com/) on every DLL in the new
ezwinports's bin/ directory, and look for the dependency DLLs that
live outside that bin/ directory -- you will surely find your offender
soon enough.

Or you can keep the ezwinports DLLs in the same directory with
emacs.exe, if you don't need to use those DLLs from other packages.

Re: strange ezwinports issue

[Sivaram Neelakantan]

On Tue, Sep 08 2015,Eli Zaretskii wrote:


[snipped 11 lines]

> There was no change that necessitated this.  What this experiment
> means is that you have a small "DLL hell" on your hands: you have an
> incompatible copy of some DLL that is used by some of the ezwinports
> that lives in some other directory which is closer to the beginning of
> your PATH than the ezwinports' bin/ directory.  So when Emacs loads,
> say, libgnutls-28.dll, and looks for its dependency DLLs, it finds
> that incompatible DLL first, tries to load it, which fails (due to
> whatever makes it incompatible), and then the load of libgnutls-28.dll
> fails because of that.
>

Right but this is a bit confusing.  You see, the version that I was
using earlier had all the DLLs under ezwinports and NOT under the
Emacs bin directory.  I renamed it as ezwinportsold and the downloaded
one as ezwinports. At this point it stopped working.  If I rename the
old one back as ezwinports again, it works.

Why does this work then?

[snipped 14 lines]



 sivaram
 -- 

Re: strange ezwinports issue

[Eli Zaretskii]

> From: Sivaram Neelakantan <nsivaram.net@gmail.com>
> Date: Thu, 10 Sep 2015 21:34:17 +0530
> 
> > There was no change that necessitated this.  What this experiment
> > means is that you have a small "DLL hell" on your hands: you have an
> > incompatible copy of some DLL that is used by some of the ezwinports
> > that lives in some other directory which is closer to the beginning of
> > your PATH than the ezwinports' bin/ directory.  So when Emacs loads,
> > say, libgnutls-28.dll, and looks for its dependency DLLs, it finds
> > that incompatible DLL first, tries to load it, which fails (due to
> > whatever makes it incompatible), and then the load of libgnutls-28.dll
> > fails because of that.
> >
> 
> Right but this is a bit confusing.  You see, the version that I was
> using earlier had all the DLLs under ezwinports and NOT under the
> Emacs bin directory.  I renamed it as ezwinportsold and the downloaded
> one as ezwinports. At this point it stopped working.  If I rename the
> old one back as ezwinports again, it works.
> 
> Why does this work then?

Probably because the previous DLLs didn't depend on that incompatible
DLL which gives you trouble now.