[Top][All Lists]

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

RE: [h-e-w] 23.0.60; cygwin1.dll dependency

From: Stephan Mueller
Subject: RE: [h-e-w] 23.0.60; cygwin1.dll dependency
Date: Mon, 18 Aug 2008 12:19:21 -0700

Thanks for the quick reply, Lennart.  I do indeed see the same problem when I 
run with -Q:

[D:\Emacs\emacsw32-23.0\emacs\bin] d:\emacs\emacsw32-23.0\emacs\bin\emacs.exe -Q
   3720 [main] ? (336) d:\emacs\emacsw32-23.0\emacs\bin\emacs.exe: *** fatal 
error - Incompatible cygwin .dll -- incompatible per_process info 0 != 168

The dependency does indeed seem a bit odd.  Originally, I leapt to the theory 
(sorry) mentioned below (based on dim recollections about patched emacs knowing 
how to find cygwin itself, which is now clearly not related) but now that you 
say there's no dependency, I've dug a little deeper.

I've tried running the above command under depends.exe and it appears that 
emacs.exe is loading libxpm.dll from my cygwin installation, and that's loading 
libx11.dll from cygwin and that's finally loading cygwin1.dll.  When I remove 
just the cygwin X11 directory from my path, emacs no longer loads libxpm.dll 
(makes sense; libx11.dll is no longer available) and instead finds the xpm4.dll 
from the directory containing emacs.exe.  It appears that the reason for 
wanting xpm support at boot is to show the GNU Emacs icon on the startup 
screen.  At this point, depends.exe still shows that emacs spawns other things 
from cygwin (e.g. aspell.exe) that use cygwin1.dll, but doesn't appear to load 
cygwin1.dll itself -- excellent.

Digging even deeper, I find that I can probably (just haven't tried it yet) 
manipulate the xpm entry in image-library-alist to avoid trying to load the 
unsuitable libxpm in the first place.  Ultimately, I may also want to see if 
the libxpm in my cygwin installation is old or otherwise damaged -- but I 
suspect that it may simply be the case that cygwin DLLs are inappropriate to 
load into non-cygwin processes, period.

One last possibility is to find a compatible libXpm.dll and place that in the 
emacs bin directory, next to (or instead of) xpm4.dll.  I find that the FSF 
emacs-22.2 distribution includes such a dll.  I've placed that next to 
emacs.exe and the problem is solved.  Renaming xpm4.dll provided with emacsw32 
to libXpm.dll also seems to work (but while that's nifty in that it requires 
nothing not already included in emacsw32 and xpm4.dll is tiny compared to the 
emacs-22.2-included libxpm.dll, it seems a little 'sleazy' in that it's a lie 
about what code is really there).

Given that libXpm.dll is earlier in the default definition of 
image-library-alist, I wonder if including libxpm.dll in emacsw32 over xpm4 
would be preferable.  More generally, I wonder if including DLLs that are each 
first in their respective image-library-alist entries would be ideal, reducing 
emacs' vulnerability to random stuff on the user's machine.  But that's of 
course entirely up to you, Lennart; thanks for providing emacsw32!

thanks for your time,
From: Lennart Borgman (gmail) address@hidden
Sent: Monday, August 18, 2008 7:17 AM
To: Stephan Mueller
Cc: address@hidden
Subject: Re: [h-e-w] 23.0.60; cygwin1.dll dependency

Stephan Mueller wrote:
 > Using Lennart's patched Emacs.
 > I have a current Cygwin installation with many packages.  Note that I'm
 > running
 > with cygwin 1.5 -- not the experimental 1.7:
 > [D:\Emacs\emacsw32-23.0\emacs\bin] cygcheck -c cygwin
 > Cygwin Package Information
 > Package              Version        Status
 > cygwin               1.5.25-15      OK
 > When I attempt to launch patched emacs, it generates the following
 > at the console prompt from which it was launched; while the emacs
frame is
 > displayed, it is unusuable (program is non-responsive).
 > [D:\Emacs\emacsw32-23.0\emacs\bin] .\emacs.exe
 >     172 [main] ? (3944) D:\Emacs\emacsw32-23.0\emacs\bin\emacs.exe: ***
 > fatal er
 > ror - Incompatible cygwin .dll -- incompatible per_process info 0 != 168
 > Renaming my copy of cygwin1.dll in the cygwin installation before
 > emacs suppresses the problem.
 > This behaviour did not occur with the previous Emacsw32 version I was
 > (a build based on emacs 22).  Perhaps I didn't see it because the
 > emacs was compatible with the cygwin version I have?
 > Ideally, emacsw32 would not be bound to any particular version of cygwin,
 > so that it could be compatible with both current and experimental
 > installations.
 > Thanks.
 > In GNU Emacs (i386-mingw-nt5.1.2600)
 >  of 2008-08-13 on LENNART-69DE564 (patched)

Thanks for the bug report Stephan.

This is a strange error and I do not understand where it comes from.
There should be no dependencies on cygwin1.dll in a Emacs+EmacsW32.

Could you please (with cygwin1.dll in its place) try to start Emacs with


Do you still see the problem with the cygwin1.dll then?

reply via email to

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