(Merging responses somewhat)
Lennart Borgman wrote:
" Eli Zaretskii wrote:
" >> Date: Mon, 18 Aug 2008 21:49:26 +0200
" >> From: "Lennart Borgman (gmail)" <[EMAIL PROTECTED]>
" >> CC: "help-emacs-windows@gnu.org" <help-emacs-windows@gnu.org>,
" >> Eli Zaretskii <[EMAIL PROTECTED]>
" >>
" >> Now I wonder what to do with the image libraries. This problem is of
" >> course not only a problem for Emacs+EmacsW32. The same thing that
" >> happened here could happen to anyone using Emacs on ms windows.
" >>
" >> Eli, do you have any suggestion? Who knows more about the image libraries?
" >
" > My only suggestion is not to mix Cygwin and non-Cygwin executables.
" > Segregate them by preparing 2 scripts, on each for switching to each
" > of the two environments, and run the right one before using the first
" > executable from a different environment.
"
" Thanks, I wonder if not more can be done, but let us move this
" discussion to the devel list.
I'm not on the devel list, so will make my verbose parting comments
here and further below.
Looking at my old EmacsW32 installation, based on emacs 22, I notice
that the default value of image-library-alist appears to have changed
since then in my new EmacsW32 based on emacs 23. Specifically, the
first entry used to be:
(xpm "xpm4.dll" "libXpm-nox4.dll" "libxpm.dll")
and now it's:
(xpm "libxpm.dll" "xpm4.dll" "libXpm-nox4.dll")
... which would pretty directly explain why I only had the problem
starting with emacs23.
So, Lennart, I would say that to 'keep pace' with this change, you
may simply want to include libxpm.dll in EmacsW32 instead of
xpm4.dll. libxpm.dll is also what is included in the FSF emacs-22.2
Windows build distribution.
Curiously, the help text for image-library-alist mentions that "'pbm
and 'xpm don't actually need to be listed as they're always
supported". I'm not sure if that support is because libxpm.dll is
always in the distribution and loaded if all else fails, or if there's
in-built support in emacs.exe. Regardless, xpm is listed, and to live
up to the claim of always being supported, including the first named
DLL for this particular format seems prudent to me, if just to allow
seeing the emacs startup screen with its impressive new anti-aliased
gnu, instead of a hang, on first boot :-)
There have been other changes in image-library-alist as well, and you
may want to keep up with them too: libpng12d.dll is now the first png
library looked for, and there are new entries for svg (librsvg-2-2.dll),
gdk-pixbuf (libgdk_pixbuf-2.0-0.dll) and glib (libglib-2.0-0.dll).
While gif's list is unchanged, it's currently in danger the same way
xpm is: the library you provide (libungif.dll) is not first in the
list (giflib4.dll is).
Understood about the dangers (my bad) of mixing environment, and I
don't know how common that is, so I'm not sure it's that big a deal.
Then again, much of the attraction of EmacsW32 is that it's easy for
neophytes and It Just Works, so protecting them from their own mistakes
would be nice. Up to you, of course.
" >> And another question: Where can I get depends.exe that you mention,
Stephan?
" >
" > It's part of the MS Support Tools package, which you can download from
" > the MS site.
As another reader writes, you can also find it at www.dependencywalker.com.
That is (see the site; it's a very straightforward, clean page) another
venue for the same depends as from the MS site.
<digression topic!='emacs'>
Running depends.exe on another exe will give a nice display of all the
staticly determinable dependencies of that exe. What was especially
helpful here was the profiling ability: see the Profiling menu and
"Start Profiling". This will run the exe and monitor the LoadLibrary
calls to find stuff that's not determinable statically. You may want
to uncheck "Automatically open and profile child processes" in the
preferences pane that pops up after you choose "Start profiling", to
stay focused on emacs.exe.
</digression>
Jason Rumney wrote:
" Stephan Mueller wrote:
" > 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.
" You could just rename xpm4.dll. They are just different names used by
" different builds of the same library.
Thanks. That also seemed to work. I'm not familiar with the different
sources and builds of the xpm code, and so am unclear on why there are
differently named builds with different sets of overlapping
entrypoints. Point being, I'm reluctant to lie to the computer
without knowing more :-) That said, xpm4.dll does appear to be
'better', offering more entrypoints in a far smaller DLL, so copying
that may be best after all, even if it is a lie.
" Lennart Borgman (gmail) wrote:
" > Now I wonder what to do with the image libraries. This problem is of
" > course not only a problem for Emacs+EmacsW32. The same thing that
" > happened here could happen to anyone using Emacs on ms windows.
"
" Hence the advice from Cygwin folks not to include Cygwin in the
" system-wide PATH. This can happen with any Windows program that loads
" DLLs that happen to have the same name as Cygwin DLLs, which is common
" with ported software.
<digession topic!='emacs'>
I'm surprised I've missed that advice over the years, but perhaps
I've just forgotten. Ultimately, I really don't want to do what
Jason and Eli suggest here because it largely defeats my purpose
in having Cygwin: I need to be able to us ls and rm etc. in cmd.exe
windows. My fingers know those commands from basically every
system I've used -- not all of them Unixish -- so my point is
to have familiar commands in the shell I must use, and not so
much to have a "full Unix" nearby (although that's really handy
when I do need it, too).
I do appreciate the advice though. It does seem the safest
workaround for the fundamental problem, which is that %PATH% is
used both for finding executables (my reason for merging and
generally OK) and for DLLs (which ought perhaps, decades ago, to
have been designed to search a different variable, and maybe was,
but I forget what happened to DllPath).
Generally, it's not a problem for me because I do have the path
ordered differently in different environment: cmd.exe has cygwin
stuff late, Cygwin bash has cygwin stuff early. The net result is
that programs tend to find DLLs from within their own environment,
while allowing finding exes from either environment. It's only
become an issue here because emacs wants DLLs for which there is
no native copy on my machine. Knowing that, I can construct
workarounds as necessary.
</digression>
Again, thanks all for the help.
