bug#6837: Cannot view PNG images

bug#6837: Cannot view PNG images

[nyc4bos]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

With the new Emacs windows binary dated 2010-08-09, I cannot view images
such as the splash screen and the Gnus initial screen.

Looking at the *Message* buffer, I see errors such as:

PNG error: Incompatible libpng version in application and library
PNG warning: Application was compiled with png.h from libpng-1.4.3
PNG warning: Application  is  running with png.c from libpng-1.2.37


Appartently, something has changed since the Emacs windows binary version
dated 2010-08-02 with respect to the PNG libraries (libpng3.dll and
libpng12.dll), that the current Emacs windows binary dated 2010-08-09
wont display PNG images.  It just shows an empty box.


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
f:/emacs-24.0.50/etc/DEBUG.


In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-08-09 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags -Ic:/imagesupport/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp949
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<wheel-up> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <menu-bar> <help-menu> <se
nd-emacs-bug-report>

Recent messages:
PNG error: Incompatible libpng version in application and library
PNG warning: Application was compiled with png.h from libpng-1.4.3
PNG warning: Application  is  running with png.c from libpng-1.2.37
PNG error: Incompatible libpng version in application and library
PNG warning: Application was compiled with png.h from libpng-1.4.3
PNG warning: Application  is  running with png.c from libpng-1.2.37
PNG error: Incompatible libpng version in application and library
PNG warning: Application was compiled with png.h from libpng-1.4.3
PNG warning: Application  is  running with png.c from libpng-1.2.37
PNG error: Incompatible libpng version in application and library

Load-path shadows:

Features:
(shadow sort gnus-util mail-extr message rfc822 mml easymenu mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32
disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mldrag mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev button minibuffer faces cus-face files text-properties overlay
md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)

bug#6837: Cannot view PNG images

[Jason Rumney]

On 11/08/2010 05:46, nyc4bos@aol.com wrote:
> Looking at the *Message* buffer, I see errors such as:
>
> PNG error: Incompatible libpng version in application and library
> PNG warning: Application was compiled with png.h from libpng-1.4.3
> PNG warning: Application  is  running with png.c from libpng-1.2.37
>    

The message is quite self explanatory. You need to update your libpng 
installation.

bug#6837: closed (Re: bug#6837: Cannot view PNG images)

[nyc4bos]

On 11/08/2010 11:16, Jason Rumney <jasonr@gnu.org> wrote:
>On 11/08/2010 05:46, nyc4bos@aol.com wrote:
>> Looking at the *Message* buffer, I see errors such as:
>>
>> PNG error: Incompatible libpng version in application and library
>> PNG warning: Application was compiled with png.h from libpng-1.4.3
>> PNG warning: Application  is  running with png.c from libpng-1.2.37
>>    
>
>The message is quite self explanatory. You need to update your libpng
>installation.

Unfortunately, the only libpng library available to me that I could
find is from http://gnuwin32.sourceforge.net/packages/libpng.htm
which is libpng.2.37.  They don't have the 1.4.x series for windows.

bug#6837: Cannot view PNG images

[Andy Moreton]

On Wed 11 Aug 2010, Jason Rumney wrote:

> On 11/08/2010 05:46, nyc4bos@aol.com wrote:
>> Looking at the *Message* buffer, I see errors such as:
>>
>> PNG error: Incompatible libpng version in application and library
>> PNG warning: Application was compiled with png.h from libpng-1.4.3
>> PNG warning: Application  is  running with png.c from libpng-1.2.37
>>    
> The message is quite self explanatory. You need to update your libpng
> installation.

I have also encountered this problem with the prebuilt Win32 binaries.
I've built libpng14.dll and zlib1.dll from upstream sources. To get
emacs to use the new DLLs, I had to update image-library-alist to
include the new DLL name.

It would be helpful for users of binary emacs packages if the image
handling was improved as follows:

1) Display the image DLL version mismatch message in the minibuffer
as well as in the *Messages* buffer, as it is not immediately obvious
what the problem is.

2) Do not cache the results of the image DLL lookup. If the required
DLLs are copied to the emacs/bin directory after emacs is started, it
requires a restart to notice that the DLL is now available.

3) Make the required image DLL version number available at the lisp
level alongside image-library-alist, so the user can determine which
version of the DLL they need to build.

    AndyM

bug#6837: Cannot view PNG images

[Juanma Barranquero]

On Fri, Aug 13, 2010 at 11:12, Andy Moreton <andrewjmoreton@gmail.com> wrote:

> I have also encountered this problem with the prebuilt Win32 binaries.
> I've built libpng14.dll and zlib1.dll from upstream sources. To get
> emacs to use the new DLLs, I had to update image-library-alist to
> include the new DLL name.

Having to set up `image-library-alist' is not a bug. That's what the
variable is for.

> 1) Display the image DLL version mismatch message in the minibuffer
> as well as in the *Messages* buffer, as it is not immediately obvious
> what the problem is.

Image error messages are not treated diferently than other errors.

> 2) Do not cache the results of the image DLL lookup. If the required
> DLLs are copied to the emacs/bin directory after emacs is started, it
> requires a restart to notice that the DLL is now available.

For this to work correctly, Emacs on Windows would be forced to check
(either unloading/loading the library or looking at the library's path
and/or timestamp) on *every* access to one of the library's functions.
It's much easier to live with this limitation (which is documented on
nt/INSTALL). BTW, not that it is relevant, but note that the image
libraries need not to be on the bin/ directory of Emacs, they could be
anywhere in the PATH (which is not limited to the setting of the PATH
environment variable; it's also affected by the App Paths registry
entry, etc.), or even outside the PATH if the relevant
image-library-alist entry has been added.

> 3) Make the required image DLL version number available at the lisp
> level alongside image-library-alist, so the user can determine which
> version of the DLL they need to build.

How do you determine the required image DLL version? Emacs is compiled
with a given set of #includes, but there's no general way to determine
whether older or newer releases will be compatible or not. If the
library is able to determine that it is not, and gives an error
message (like the one originating this bug report), it's easy to
determine that there's a version mismatch.

It could be possible to make available the version of each library
used to compile the running binary, but again, that does not offer
much information about which versions are compatible.

    Juanma

bug#6837: Cannot view PNG images

[Andy Moreton]

[-- Attachment #1: Type: text/plain, Size: 2466 bytes --]

On 24 September 2010 22:19, Juanma Barranquero <lekktu@gmail.com> wrote:

> On Fri, Aug 13, 2010 at 11:12, Andy Moreton <andrewjmoreton@gmail.com>
> wrote:
>
> > I have also encountered this problem with the prebuilt Win32 binaries.
> > I've built libpng14.dll and zlib1.dll from upstream sources. To get
> > emacs to use the new DLLs, I had to update image-library-alist to
> > include the new DLL name.
>
> Having to set up `image-library-alist' is not a bug. That's what the
> variable is for.
>

I didn't imply it was a bug, but that some user configuration was required.
 It would be helpful to add the new DLL name to the list.

>
>
> > 2) Do not cache the results of the image DLL lookup. If the required
> > DLLs are copied to the emacs/bin directory after emacs is started, it
> > requires a restart to notice that the DLL is now available.
>
> For this to work correctly, Emacs on Windows would be forced to check
> (either unloading/loading the library or looking at the library's path
> and/or timestamp) on *every* access to one of the library's functions.
> It's much easier to live with this limitation (which is documented on
> nt/INSTALL). BTW, not that it is relevant, but note that the image
> libraries need not to be on the bin/ directory of Emacs, they could be
> anywhere in the PATH (which is not limited to the setting of the PATH
> environment variable; it's also affected by the App Paths registry
> entry, etc.), or even outside the PATH if the relevant
> image-library-alist entry has been added.
>

Sorry, I did not express myself clearly here. The case I considered was when
image DLL lookup fails, and emacs no longer bothers looking. It would be
helpful if emacs tried to locate the image DLL again the next time image
display is required.

> 3) Make the required image DLL version number available at the lisp
> > level alongside image-library-alist, so the user can determine which
> > version of the DLL they need to build.
>
[snipped]

>
> It could be possible to make available the version of each library
> used to compile the running binary, but again, that does not offer
> much information about which versions are compatible.
>
> This is exactly what I was suggesting. Once you know the versions of the
headers that emacs was built with, you can then search the web to discover
if the installed DLL is compatible. While this still may not solve the
problem, it help to know which version of the DLL to look for.

    AndyM

[-- Attachment #2: Type: text/html, Size: 3424 bytes --]

bug#6837: Cannot view PNG images

[Juanma Barranquero]

On Sat, Sep 25, 2010 at 20:40, Andy Moreton
<andrewjmoreton@googlemail.com> wrote:

> I didn't imply it was a bug, but that some user configuration was required.
>  It would be helpful to add the new DLL name to the list.

Which one?

> Sorry, I did not express myself clearly here. The case I considered was when
> image DLL lookup fails, and emacs no longer bothers looking. It would be
> helpful if emacs tried to locate the image DLL again the next time image
> display is required.

Yes, I understand, but again, if you're for example trying to display
a lot of images, and they are from a type not loaded, *each* function
access will try to load the library (under all known names) and fail.

> This is exactly what I was suggesting. Once you know the versions of the
> headers that emacs was built with, you can then search the web to discover
> if the installed DLL is compatible.

This bug is closed. I suggest you send that as a wishlist bug report,
so it is remembered. Better still if you want to send a patch instead
;-)

    Juanma