* bug#6837: Cannot view PNG images @ 2010-08-10 21:46 nyc4bos 2010-08-11 3:16 ` Jason Rumney [not found] ` <handler.6837.D6837.128149659126415.notifdone@debbugs.gnu.org> 0 siblings, 2 replies; 7+ messages in thread From: nyc4bos @ 2010-08-10 21:46 UTC (permalink / raw) To: 6837 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) ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#6837: Cannot view PNG images 2010-08-10 21:46 bug#6837: Cannot view PNG images nyc4bos @ 2010-08-11 3:16 ` Jason Rumney 2010-08-13 9:12 ` Andy Moreton [not found] ` <handler.6837.D6837.128149659126415.notifdone@debbugs.gnu.org> 1 sibling, 1 reply; 7+ messages in thread From: Jason Rumney @ 2010-08-11 3:16 UTC (permalink / raw) To: 6837-done 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#6837: Cannot view PNG images 2010-08-11 3:16 ` Jason Rumney @ 2010-08-13 9:12 ` Andy Moreton [not found] ` <AANLkTi=k-v8isbe67k_hbgJZRtJDv-Yc8+HT=NQS8h2X@mail.gmail.com> 0 siblings, 1 reply; 7+ messages in thread From: Andy Moreton @ 2010-08-13 9:12 UTC (permalink / raw) To: bug-gnu-emacs 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <AANLkTi=k-v8isbe67k_hbgJZRtJDv-Yc8+HT=NQS8h2X@mail.gmail.com>]
* bug#6837: Cannot view PNG images [not found] ` <AANLkTi=k-v8isbe67k_hbgJZRtJDv-Yc8+HT=NQS8h2X@mail.gmail.com> @ 2010-09-25 0:23 ` Juanma Barranquero 2010-09-25 18:40 ` Andy Moreton 1 sibling, 0 replies; 7+ messages in thread From: Juanma Barranquero @ 2010-09-25 0:23 UTC (permalink / raw) To: Andy Moreton; +Cc: 6837 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#6837: Cannot view PNG images [not found] ` <AANLkTi=k-v8isbe67k_hbgJZRtJDv-Yc8+HT=NQS8h2X@mail.gmail.com> 2010-09-25 0:23 ` Juanma Barranquero @ 2010-09-25 18:40 ` Andy Moreton 2010-09-25 20:51 ` Juanma Barranquero 1 sibling, 1 reply; 7+ messages in thread From: Andy Moreton @ 2010-09-25 18:40 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Andy Moreton, 6837 [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#6837: Cannot view PNG images 2010-09-25 18:40 ` Andy Moreton @ 2010-09-25 20:51 ` Juanma Barranquero 0 siblings, 0 replies; 7+ messages in thread From: Juanma Barranquero @ 2010-09-25 20:51 UTC (permalink / raw) To: Andy Moreton; +Cc: Andy Moreton, 6837 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <handler.6837.D6837.128149659126415.notifdone@debbugs.gnu.org>]
* bug#6837: closed (Re: bug#6837: Cannot view PNG images) [not found] ` <handler.6837.D6837.128149659126415.notifdone@debbugs.gnu.org> @ 2010-08-11 23:09 ` nyc4bos 0 siblings, 0 replies; 7+ messages in thread From: nyc4bos @ 2010-08-11 23:09 UTC (permalink / raw) To: 6837 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-09-25 20:51 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-08-10 21:46 bug#6837: Cannot view PNG images nyc4bos 2010-08-11 3:16 ` Jason Rumney 2010-08-13 9:12 ` Andy Moreton [not found] ` <AANLkTi=k-v8isbe67k_hbgJZRtJDv-Yc8+HT=NQS8h2X@mail.gmail.com> 2010-09-25 0:23 ` Juanma Barranquero 2010-09-25 18:40 ` Andy Moreton 2010-09-25 20:51 ` Juanma Barranquero [not found] ` <handler.6837.D6837.128149659126415.notifdone@debbugs.gnu.org> 2010-08-11 23:09 ` bug#6837: closed (Re: bug#6837: Cannot view PNG images) nyc4bos
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.