Re: Building Emacs on MSYS2

[Eli Zaretskii]

> From: Stephen Leake <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Sat, 16 Apr 2016 07:17:25 -0500
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >> From: Stephen Leake <address@hidden>
> >> Date: Fri, 15 Apr 2016 16:37:33 -0500
> >> Cc: address@hidden
> >>
> >> One thing I'd like to fix; my build of emacs 25 does not display png
> >> files. The binary pretest install does. I'd like to figure out the
> >> difference.
> >
> > Are both binaries in the same directory?
> 
> My build is in c:/Projects/emacs/emacs-25-build-mingw64/src (I don't
> install, so I can easily switch versions), with libpng16-16.dll in
> d:/msys64/mingw54/bin in PATH.
> 
> The error message is "Cannot display image: (Invalid image
> specification)". I traced thru some of the code that tries to open
> the image; image.c init-image-library returns nil. I haven't tried
> running under the debugger to go further.
> 
> config.h sets HAVE_PNG true.
> 
> 
> The pretest binary is in d:/Apps/emacs-25.0.90/bin, both emacs.exe and
> libpng16-16.dll; mingw64 is _not_ in PATH.
> 
> cygwin "diff" says the two dlls differ.

So this is the root cause, right there: the DLLs differ.  Where did
you get them?  Are both 64-bit DLLs?  Are they both MinGW DLLs?

> depends.exe on emacs and libpng (both builds) reports no obvious errors
> (it seems there is always something missing on windows; I assume those
> are optional Windows components).

I didn't mean errors.  Libpng should depend on zlib DLL; do you have
it? is it good? is there only one zlib DLL?

> The libpng comes from the msys2 package manager, so I assume it's all
> consistent.

Does it come with zlib DLL, or did you install zlib DLL separately?
If the latter, they could be inconsistent.

> Yes, I figured it was some obscure dll issue, which is why I have not
> tried to track it down yet. Since the problem is not present in the
> pretest, I figured it's a problem with my setup, not the Emacs sources,
> so I did not report a bug.

I don't understand why you (and others) use different PATH
arrangements to run different binaries, and have multiple versions of
support DLLs.  Isn't it clear that by doing so you create your own DLL
hell?  It's much better to have just one copy of each support DLL, in
a place that is always on PATH.