Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 412773 - app-editors/emacs-vcs: Includes incorrect libpng header file
Summary: app-editors/emacs-vcs: Includes incorrect libpng header file
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Prefix Support (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Prefix
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-20 12:46 UTC by Benjamin Motz
Modified: 2016-05-28 07:57 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info emacs-vcs emacs23 (file_412773.txt,5.78 KB, text/plain)
2012-04-20 15:22 UTC, Benjamin Motz
Details

Note You need to log in before you can comment on or make changes to this bug.
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) archtester Gentoo Infrastructure gentoo-dev Security 2012-04-20 15:06:54 UTC
Please provide "emerge --info emacs-vcs"
Comment 2 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 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 gentoo-dev 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 gentoo-dev 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 gentoo-dev 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 gentoo-dev 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 gentoo-dev 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 gentoo-dev 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 gentoo-dev 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 gentoo-dev 2014-11-12 17:05:53 UTC
Is this still an issue?
Comment 12 Ulrich Müller gentoo-dev 2016-05-28 07:57:38 UTC
(In reply to Ulrich Müller from comment #11)
> Is this still an issue?

No reply. Closing.