Bug 412773 – app-editors/emacs-vcs: Includes incorrect libpng header file

• Product: Gentoo/Alt
• Status: RESOLVED NEEDINFO

[Description Benjamin Motz 2012-04-20 12:46:21 UTC]

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.

[Comment 1 Jeremy Olexa (darkside) (RETIRED) 2012-04-20 15:06:54 UTC]

Please provide "emerge --info emacs-vcs"

[Comment 2 Jeremy Olexa (darkside) (RETIRED) 2012-04-20 15:12:07 UTC]

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)

[Comment 3 Benjamin Motz 2012-04-20 15:22:06 UTC]

Created attachment 309631 [details]
emerge --info emacs-vcs emacs23

[Comment 4 Ulrich Müller 2012-04-20 18:54:19 UTC]

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

[Comment 5 Fabian Groffen 2012-04-20 18:59:06 UTC]

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

[Comment 6 Ulrich Müller 2012-04-21 01:23:58 UTC]

(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?

[Comment 7 Fabian Groffen 2012-04-21 11:13:15 UTC]

(In reply to comment #6)
> By upstream you mean libpng upstream, I suppose?

Yes, sorry for not being clear on that.

[Comment 8 Ulrich Müller 2012-04-21 16:42:05 UTC]

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.

[Comment 9 Fabian Groffen 2012-04-21 17:48:08 UTC]

We could also export ac_have_libpng_png_h=no (or something) since that should always be the case on Gentoo systems.

[Comment 10 Ulrich Müller 2012-04-22 13:12:19 UTC]

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

[Comment 11 Ulrich Müller 2014-11-12 17:05:53 UTC]

Is this still an issue?

[Comment 12 Ulrich Müller 2016-05-28 07:57:38 UTC]

(In reply to Ulrich Müller from comment #11)
> Is this still an issue?

No reply. Closing.