Opening png-files in emacs (23/vcs) produces an error message (in *Messages*-buffer) PNG warning: Application built with libpng-1.2.44 but running with 1.5.10 This is due to the fact that emacs-VERSION/src/image.c includes <libpng/png.h> but gentoo-prefix only has <libpng15/png.h>. So the system header (1.2.44) is used. On my prefix, I was able to fix the bug by creating a symlink /usr/include/libpng/ to libpng15/ and re-emerge emacs.
Please provide "emerge --info emacs-vcs"
Further investigation: <png.h> is installed by libpng-1.5.* It is a symlink to <libpng15/png.h> My guess, for Gentoo Linux, emacs-vcs should be patched to include <png.h>. None of the libpng ebuilds in the tree provide <libpng/png.h> so the emacs-vcs package is wrong (for Gentoo anyway)
Created attachment 309631 [details] emerge --info emacs-vcs emacs23
(In reply to comment #2) > Further investigation: > > <png.h> is installed by libpng-1.5.* It is a symlink to <libpng15/png.h> > My guess, for Gentoo Linux, emacs-vcs should be patched to include <png.h>. Hm, configure.in contains a check for the header file: AC_CHECK_HEADERS(png.h libpng/png.h) And in image.c, the include depends on the result of the configure test: #ifdef HAVE_PNG #if defined HAVE_LIBPNG_PNG_H # include <libpng/png.h> #else # include <png.h> #endif #endif > None of the libpng ebuilds in the tree provide <libpng/png.h> so the > emacs-vcs package is wrong (for Gentoo anyway) I don't see what would be wrong with above configure test.
(In reply to comment #4) > (In reply to comment #2) > > Further investigation: > > > > <png.h> is installed by libpng-1.5.* It is a symlink to <libpng15/png.h> > > My guess, for Gentoo Linux, emacs-vcs should be patched to include <png.h>. > > Hm, configure.in contains a check for the header file: > > AC_CHECK_HEADERS(png.h libpng/png.h) > > And in image.c, the include depends on the result of the configure test: > > #ifdef HAVE_PNG > #if defined HAVE_LIBPNG_PNG_H > # include <libpng/png.h> > #else > # include <png.h> > #endif > #endif > > > None of the libpng ebuilds in the tree provide <libpng/png.h> so the > > emacs-vcs package is wrong (for Gentoo anyway) > > I don't see what would be wrong with above configure test. both HAVE_PNG_H and HAVE_LIBPNG_PNG_H are defined, the code just assumes that libpng/png.h should take precedence, while in this case (as per upstream), the png.h case should take precedence.
(In reply to comment #5) > both HAVE_PNG_H and HAVE_LIBPNG_PNG_H are defined, the code just assumes > that libpng/png.h should take precedence, while in this case (as per > upstream), the png.h case should take precedence. By upstream you mean libpng upstream, I suppose?
(In reply to comment #6) > By upstream you mean libpng upstream, I suppose? Yes, sorry for not being clear on that.
Well, the fix looks obvious then, namely to test for HAVE_PNG_H instead of HAVE_LIBPNG_PNG_H. But could you please report the problem to (Emacs) upstream? I'd much prefer a fix that was accepted by them.
We could also export ac_have_libpng_png_h=no (or something) since that should always be the case on Gentoo systems.
(In reply to comment #9) > We could also export ac_have_libpng_png_h=no (or something) since that > should always be the case on Gentoo systems. Such ad-hoc solutions have the disadvantage that with each version bump the maintainer must check if the variable still exists in the build system of the package. So I'd rather patch image.c. And as I said before, it would be even better if such a patch was applied upstream.
Is this still an issue?
(In reply to Ulrich Müller from comment #11) > Is this still an issue? No reply. Closing.
