Bug#638812: whitedune: FTBFS with libpng 1.5
The png_jmpbuf() macro has been in libpng since libpng-1.0.6
(March 2000).
The problem here is not that the macro is missing but that the
application was not using it!
Glenn
On Sun, Sep 11, 2011 at 11:41 PM, Nobuhiro Iwamatsu
iwama...@nigauri.org wrote:
Hi,
Thanks for your comments.
2011/9/5 Joerg Scheurich aka MUFTI
rusmu...@helpdesk.bera.rus.uni-stuttgart.de:
Hi,
I am only the upstream of white_dune, not the debian maintainer...
I noticed your package FTBFS by libpng 1.5.
I created the patch that revise this problem.
Could you check and apply this patch?
... but instead of using
#if PNG_LIBPNG_VER_MAJOR = 1 PNG_LIBPNG_VER_MINOR = 4
if (setjmp(png_jmpbuf((png_ptr
#else
if (setjmp(png_ptr-jmpbuf))
#endif
i think it would be better to use
/* The png_jmpbuf() macro, used in error handling, became available in
* libpng version 1.0.6. If you want to be able to run your code with
older
* versions of libpng, you must define the macro yourself (but only if it
* is not already defined by libpng!).
*/
#ifndef png_jmpbuf
#define png_jmpbuf(png_ptr) ((png_ptr)-jmpbuf)
#endif
...
if (setjmp(png_jmpbuf((png_ptr
accordingly to
http://www.exploit-db.com/exploits/393/
Oh, I see. Thanks!
I revise the patch of other packages.
This compiles and runs at least with libpng version 1.5.4/libpng12-dev
1.2.44-1+squeeze1 and will be part of the next development versions of
white_dune.
BTW: the lines
#ifndef png_jmpbuf
#define png_jmpbuf(png_ptr) ((png_ptr)-jmpbuf)
#endif
could be also part of a header file belonging to the libpng15-dev,
e.g. something like pnglegacy.h (cc to Greg Roelofs)
Cool. But current author are Guy Eric Schalnat, Andreas Dilger, John
Bowler and Glenn Randers-Pehrson.
Could you cc to current authors?
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#468645: libpng12-0: sample code uses deprecated function
On Sat, Oct 4, 2008 at 5:57 PM, Aníbal Monsalve Salazar [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 01:48:32PM -0500, Glenn Maynard wrote: /usr/share/doc/libpng12-0/examples/example.c.gz uses the function png_set_gray_1_2_4_to_8, which is deprecated. Thanks. This will be fixed in libpng-1.2.33beta01 and libpng-1.4.0beta35. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401044: libpng12-dev: [AMD64] asm API functions not exported
On 12/3/06, Anibal Monsalve Salazar [EMAIL PROTECTED] wrote: On Sat, Dec 02, 2006 at 10:25:13PM -0500, Glenn Randers-Pehrson wrote: Try just-released libpng-1.2.15beta1 It has a revised configure.ac and configure, using some of Daniel's ideas. The soname won't have to change when we release 1.2.15. Glenn libmagick didn't build with libpng-1.2.15beta1. Well, Daniel said: It requires further changes to imagemagick that currently uses neither libpng-config nor pkg-config Libpng-1.2.15beta1 only puts the PNG_NO_ASSEMBLER_CODE define into libpng-config and libpng-pc, so ImageMagick needs to be modified to consult one of those. Are libpng.pc and libpng-config built correctly now on your platform? Perhaps the best fix is to just brute-force always set PNG_NO_ASSEMBLER_CODE in imageMagick, until libpng-1.4.0 is released. Glenn See: Sun, 03 Dec 2006 15:39:22 +1100 d5 amd64 linda 0.3.24 lintian 1.23.25 pbuilder 0.160 piuparts 0.20-3 I: using fakeroot in build. pbuilder-buildpackage/amd64 $Id: pbuilder-buildpackage-funcs,v 1.31 2006/05/30 23:45:45 dancer Exp $ $Id: pbuilder-buildpackage,v 1.127 2006/08/15 13:14:25 dancer Exp $ [...] Setting up libpng12-0 (1.2.15~beta1-0) ... Setting up libpng12-dev (1.2.15~beta1-0) ... [...] /bin/sh ./libtool --silent --tag=CC --mode=link gcc -g -O2 -Wall -pthread -L/usr/lib/X11 -lfreetype -lz -L/usr/lib -o utilities/animate -L/usr/lib/X11 -lfreetype -lz -L/usr/lib utilities/animate.o magick/libMagick.la magick/.libs/libMagick.so: undefined reference to `png_set_asm_flags' magick/.libs/libMagick.so: undefined reference to `png_get_asm_flags' collect2: ld returned 1 exit status make[1]: *** [utilities/animate] Error 1 make[1]: Leaving directory `/tmp/buildd/imagemagick-6.2.4.5.dfsg1' make: *** [build-stamp] Error 2 pbuilder: Failed autobuilding of package Aníbal Monsalve Salazar -- http://v7w.com/anibal -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFFcmCXgY5NIXPNpFURAuujAJ9SPAyxRKg5/hZzayyjCMc8nXRgiQCfXd7x 9AiPu62Rrq8Tg7JB1sbSnIE= =GiS0 -END PGP SIGNATURE-
Bug#401044: libpng12-dev: [AMD64] asm API functions not exported
Try libpng-1.2.15beta2 It provides stub asm functions regardless of the PNG_NO_ASSEMBLER_CODE setting, therefore the API doesn't change. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401044: libpng12-dev: [AMD64] asm API functions not exported
Try just-released libpng-1.2.15beta1 It has a revised configure.ac and configure, using some of Daniel's ideas. The soname won't have to change when we release 1.2.15. Glenn On 12/2/06, Aníbal Monsalve Salazar [EMAIL PROTECTED] wrote: On Fri, Dec 01, 2006 at 07:57:34PM -0500, Glenn Randers-Pehrson wrote: On 12/1/06, Anibal Monsalve Salazar [EMAIL PROTECTED] wrote: On Fri, Dec 01, 2006 at 11:50:51AM +0100, Daniel Kobras wrote: On Fri, Dec 01, 2006 at 08:46:00PM +1100, Anibal Monsalve Salazar wrote: I built libpng_1.2.14-0_amd64 and then I tried to build imagemagick_6.2.4.5.dfsg1-0.12_amd64 and it failed: Sorry, apart from the problem with libpng, there's also a bug in imagemagick. You need to apply the patch from #401047 to -0.12. I have a fixed -0.13 ready, but it's not uploaded yet because with current libpng it would fail to build just a few lines later with a linker error. With that patch, my amd64 build ends with: [...] Setting up libpng12-0 (1.2.14-0) ... [...] Setting up libpng12-dev (1.2.14-0) ... [...] /bin/sh ./libtool --silent --tag=CC --mode=link gcc -g -O2 -Wall -pthread -L/usr/lib/X11 -lfreetype -lz -L/usr/lib -o utilities/animate -L/usr/lib/X11 -lfreetype -lz -L/usr/lib utilities/animate.o magick/libMagick.la magick/.libs/libMagick.so: undefined reference to `png_set_asm_flags' magick/.libs/libMagick.so: undefined reference to `png_get_asm_flags' collect2: ld returned 1 exit status make[1]: *** [utilities/animate] Error 1 make[1]: Leaving directory `/tmp/buildd/imagemagick-6.2.4.5.dfsg1' make: *** [build-stamp] Error 2 pbuilder: Failed autobuilding of package So, libpng 1.2.14 doesn't fix the problem. Right, it has the same code as libpng-1.2.12 in configure.ac: # Config files, substituting as above AC_CONFIG_FILES([Makefile libpng.pc:scripts/libpng.pc.in]) AC_CONFIG_FILES([libpng-config:scripts/libpng-config.in], [chmod +x libpng-config]) This needs to be expanded to include the information from @LIBPNG_DEFINES@ in both libpng.pc and libpng-config. I don't know how to do that. Alternatively, use libpng-1.4.0beta16, which takes a different, probably more robust approach of building pngdefs.h with the information. imagemagick builds with libpng-1.4.0beta16, the results are at: http://people.debian.org/~anibal/imagemagick/ I'll intend to upload libpng_1.4.0~beta16-0 to experimental. The transition to the new libpng soname will be problematic as there is a considerable number of reverse dependencies and there is also a number of circular dependencies involving libpng. IMHO, the release managers will not approve this transition. Aníbal Monsalve Salazar -- http://v7w.com/anibal -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFFcgdFgY5NIXPNpFURApuCAJ9fR44E70yhAna6CXVM5IVF23DEDQCg1lTq +JnsdehLRlw6lQkFHpgWhng= =Lsxb -END PGP SIGNATURE-
Bug#401044: libpng12-dev: [AMD64] asm API functions not exported
At 08:46 PM 12/1/2006 +1100, Anibal Monsalve Salazar wrote: On Thu, Nov 30, 2006 at 11:40:11PM -0500, Glenn Randers-Pehrson wrote: At 02:26 PM 12/1/2006 +1100, you wrote: Does libpng-1.4.0beta16 work? I couldn't find it at: ftp://ftp.simplesystems.org/pub/libpng/png/src/ The betas are at ftp://ftp.simplesystems.org/pub/png-group/src/ and http://libpng.sourceforge.net/ (in the DOWNLOAD area) Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401044: libpng12-dev: [AMD64] asm API functions not exported
Date: Fri, 1 Dec 2006 11:50:51 +0100 From: Daniel Kobras [EMAIL PROTECTED] To: Anibal Monsalve Salazar [EMAIL PROTECTED] Cc: Glenn Randers-Pehrson [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Bug#401044: libpng12-dev: [AMD64] asm API functions not exported User-Agent: Mutt/1.5.13 (2006-08-11) On Fri, Dec 01, 2006 at 08:46:00PM +1100, Anibal Monsalve Salazar wrote: I built libpng_1.2.14-0_amd64 and then I tried to build imagemagick_6.2.4.5.dfsg1-0.12_amd64 and it failed: Sorry, apart from the problem with libpng, there's also a bug in imagemagick. You need to apply the patch from #401047 to -0.12. I have a fixed -0.13 ready, but it's not uploaded yet because with current libpng it would fail to build just a few lines later with a linker error. If you are speaking of the png_ptr - ping and the png_access_version_number() errors, those are already checked in to upstream ImageMagick. If it's something else, please let me know. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401044: libpng12-dev: [AMD64] asm API functions not exported
At 12:51 AM 12/1/2006 +0100, Daniel Kobras wrote: On Fri, Dec 01, 2006 at 09:28:23AM +1100, Aníbal Monsalve Salazar wrote: -checking if assembler code in pnggccrd.c can be compiled... no +checking if assembler code in pnggccrd.c can be compiled... yes The configure script cannot compile assembler code in pnggccrd.c on amd64, whereas on i386 it can. I see. This is inconsistent with the #define magic in pngconf.h that controls whether the asm functions are exported. Specifically, it's the __MMX__ #define that our cpp emits by default on amd64, but not on i386. Also, the functions in question live in pngset.c, rather than pnggccrd.c, and they're wrapped with PNG_ASSEMBLER_CODE_SUPPORTED instead of PNG_USE_PNGGCCRD. So am I seeing this right: Not only does libpng change its API based on configure checks, it also tries to second guess its own configuration from default macros in pngconf.h, rather than simply autogenerating this file with proper contents? Yay. Yes, that's pretty much it. Libpng-1.4.0beta16 does autogenerate a pngdefs.h file with proper contents. We tried to autogenerate pngconf.h in libpng-1.2.12beta but failed (we always got dependency problems and pngconf.h wouldn't get updated in time). Please direct the yay to the people who are flooding the market with machines that broadcast __MMX__ but are unable to assemble MMX code. That happened after libpng began using __MMX__ to separate the sheep from the goats. Anibal, please forward to the debian.orgs addressees, who bounce comcast. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
