Mozilla's libpng is mostly 1.0.2, but pngconf.h is 0.95. Because Mozilla never includes system PNG headers even if it links against the system libpng, this results in inconsistent data structures when attempting to use native (system) PNG libraries for the build. Fix: replace modules/libimg/png/pngconf.h with the stock version from 1.0.2. Note that this also eliminates the requirement to include any sort of libpng.so or libpng.so.2 symlink in dist/bin, which I thought was an issue for bug 5459. There is also no apparent problem with libc5 vs. glibc2 (or ld.so.1 vs ld.so.2).

on it. Thanks for catching this one, G. -pn

I've got to sort out if any of the diffs are still needed. -pn

> I've got to sort out if any of the diffs are still needed. If they are, then MOZ_NATIVE_PNG compiles are also broken. I'd rather go with a completely stock libpng and fix any new breakage (preferably in Mozilla itself) than continue carrying along old fixes of questionable validity. The only problems I expect to see have to do with setjmp/longjmp and inconsistent notions of the size of jmp_buf between library and application; those should go away as soon as I install a custom libpng error handler (which will be required in some future version of libpng anyway).

I agree that a stock png implementation makes sense. but I'm not going to check in the 'new' pngconf.h without having an idea what it will do on several platforms. So far, its ok on my NT and Linux. Hopefully will be able to check Mac and solaris soon. -pn

Builds ok on Mac, linux, NT. Checked in 1.02 pngconf.h file. This check in will result in bad displays of colormapped png images with alpha or transparency. This problem will be addressed in bug#917. There is no need to file another bug. -pnunn

Thanks, Pamela! I'll contact you separately about 917 and a PNG-flavored gif_struct with line buffers. (I guess 917 is M6 now. :-) )

[Per e-mail, QA assigning to Greg, since build stuff is out of my domain of clue. Thanks, Greg!]

Marking as verified...