When building with a native (system) libpng, Mozilla links libnspng.so against the system library but compiles it with its own png.h and pngconf.h. This was already the cause of bug 5841, but it is guaranteed to happen again for other system libpng versions, either past or future. This is probably also a problem with the native libjpeg builds and libnsjpg.so.

FYI, if this does happen with libjpeg you should see libjpeg error exits with "Wrong JPEG library version: library is %d, caller expects %d" or "JPEG parameter struct mismatch: library thinks size is %u, caller expects %u". I do not recall whether libpng has any comparable defenses.

libpng checks version numbers, but that's encoded in png.h and didn't trigger here (only pngconf.h is bogus). I suspect the bug had to do with the size of jmp_buf, which in turn would affect the size of the main png_struct. But I don't think there are any libpng tests for that. In any case, I assume you generally want to compile with a consistent libjpeg header file regardless of whether any gross inconsistencies are reported at runtime. Subtle bugs are even worse (he said with feeling).

I'm on it. -pn

Looks like the config scripts are always looking the dist directory for exported headers. Still digging, pn

Ramiro said that you get the autoconf/build related problems. I'd be happy to work with you on this, but I need some help. I looked at autoconf yesterday and got a headache. It looks to me like we use the dist/includes always. which could give us a different version of the include.

I'll take this. I think I know (sort of) how to fix this. We'll see if I'm as smart as I think I am.... ;-)

OK, this one is pilot error (I don't even know if there's a documentation issue since I haven't looked lately :-) ). The problem is that "make clobber" doesn't wipe dist/include; you have to do "make clobber_all". I did that last night, reconfigured and rebuilt; it never links its own copy of the PNG headers into dist/include (which is good for MOZ_NATIVE_PNG), and everything still works (e.g., http://www.cdrom.com/pub/png/pngs-img.html). I'll go ahead and change the resolution to INVALID. Many thanks to Christopher Seawood (offline e-mails) for helping resolve this.

*** Bug 5803 has been marked as a duplicate of this bug. ***

Rubber-stamping Verified/Invalid, since Briano Is Always Right. (tm)