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]
