[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: png in emacs 25 mingw64
From: |
Stephen Leake |
Subject: |
Re: png in emacs 25 mingw64 |
Date: |
Sat, 16 Apr 2016 15:34:16 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) |
TLDR; I usually have Cygwin in the PATH as well; it has shell tools I
can't get in Mingw (yet). It turns out that is the problem; if I run my
build of Emacs from a Mingw64 shell (no Cygwin in PATH), it can show
PNGs.
More details below.
Question; exactly which path is searched for DLLs? I have two:
PATH from the parent process
exec-path after editing in ~/.emacs
The png image is opened well after ~/.emacs is processed, so does it
look on the edited exec-path for the dll?
Or does the dll search take place during startup, in which case it is
the parent PATH (or exec-path before editing in ~/.emacs).
Eli Zaretskii <address@hidden> writes:
>> 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.
I don't see why that has to be the problem; the difference could be in
some date.
> Where did
> you get them?
One from the MSYS2 distribution, the other from the pretest binary,
which may have been built with the MSYS2 distribution, but I'm not sure.
>Are both 64-bit DLLs? Are they both MinGW DLLs?
I don't know how to tell.
>> 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;
Yes; zlib1.dll
>do you have
> it?
Yes; in the respective distributions.
>is it good?
I don't know how to tell. I guess I need to find some other Mingw64
program that uses it?
>is there only one zlib DLL?
In PATH for each build, yes. Although "type -a zlib1.dll" says "not
found", so it's hard to be sure.
>> 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.
Still from the package manager. Yes, the packages could be inconsistent
with each other.
>> 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.
If I want to use the Mingw distribution, I use that path.
If I want to use the Emacs pretest binary distribution, I use that path.
I do _not_ mix distributions.
I have no idea how the Emacs pretest was built; simply assuming it is
the same as my current Mingw installation is almost guarranteed to be
false.
That's what PATH is for.
>Isn't it clear that by doing so you create your own DLL
> hell?
No, I'm avoiding it by not mixing distributions.
>It's much better to have just one copy of each support DLL, in
> a place that is always on PATH.
That would be nice. I can do that on Debian, that has only one package
manager, and a rigorous distribution policy.
I could do that on Windows by only using MSYS2. But then I would not be
able to use the Emacs pretest.
Hmm. I do usually have Cygwin in the PATH as well; it has shell tools I
can't get in Mingw (yet). It turns out that is the problem; if I run my
build of Emacs from a Mingw64 shell (no Cygwin in PATH), it can show
PNGs.
So your point about mixing distributions is valid; I was not being
careful enough. Most of the time it's not a problem (this is the first
problem I can remember).
--
-- Stephe
- Re: Building Emacs on MSYS2, (continued)
- Re: Building Emacs on MSYS2, Óscar Fuentes, 2016/04/15
- Re: Building Emacs on MSYS2, Eli Zaretskii, 2016/04/15
- Re: Building Emacs on MSYS2, Stephen Leake, 2016/04/15
- Re: Building Emacs on MSYS2, Óscar Fuentes, 2016/04/15
- Re: Building Emacs on MSYS2, Eli Zaretskii, 2016/04/16
- Fixing imagemagick on W32, Stephen Leake, 2016/04/17
- Re: Fixing imagemagick on W32, Eli Zaretskii, 2016/04/17
- Re: Building Emacs on MSYS2, Eli Zaretskii, 2016/04/16
- Re: Building Emacs on MSYS2, Stephen Leake, 2016/04/16
- Re: Building Emacs on MSYS2, Eli Zaretskii, 2016/04/16
- Re: png in emacs 25 mingw64,
Stephen Leake <=
- Re: png in emacs 25 mingw64, Stephen Leake, 2016/04/16
- Re: png in emacs 25 mingw64, Eli Zaretskii, 2016/04/16
- Re: png in emacs 25 mingw64, Eli Zaretskii, 2016/04/16
- Re: Building Emacs on MSYS2, Phillip Lord, 2016/04/18
- Re: Building Emacs on MSYS2, Stefan Monnier, 2016/04/15
- Re: Building Emacs on MSYS2, Óscar Fuentes, 2016/04/15
- Re: Building Emacs on MSYS2, Stefan Monnier, 2016/04/15
- Re: Building Emacs on MSYS2 (was: Build failure for Emacs master), Eli Zaretskii, 2016/04/14
- Re: Building Emacs on MSYS2, Óscar Fuentes, 2016/04/14
- Re: Building Emacs on MSYS2, Eli Zaretskii, 2016/04/14