[Top][All Lists]

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

Re: Building Emacs on MSYS2

From: Stephen Leake
Subject: Re: Building Emacs on MSYS2
Date: Sat, 16 Apr 2016 07:17:25 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt)

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.

> Is the libpng DLL on PATH or
> with one of the binaries?  Do you have more than one libpng DLL, one
> of which might be in conflict with the w64 build, or from a different
> version of libpng, or lacks its own support libraries?

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

depends.exe says emacs.exe does not depend on libpng; I assume that's
because emacs only loads it if it is present.

> What is the
> version of libpng whose header files are visible when you build your
> own Emacs, and are those headers from the same version of libpng as
> the DLL you have installed?

The libpng comes from the msys2 package manager, so I assume it's all
consistent. How do I discover the version of the dll to check?

> These are some of the reasons that might explain the problem.  In
> general, it's most probably some kind of DLL hell.

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.

-- Stephe

reply via email to

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