5842 - native-libpng builds compile with Mozilla libpng header files

Status: VERIFIED INVALID

(Core :: Graphics: ImageLib, defect, P3)

Description

[Greg Roelofs]

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.

Comment 1

[Tom Lane]

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.

Comment 2

[Greg Roelofs]

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).

Comment 3

[pnunn]

I'm on it.
-pn

Comment 4

[pnunn]

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

Comment 5

[pnunn]

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.

Comment 6

[Brian Ostrom]

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.... ;-)

Comment 7

[Greg Roelofs]

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.

Comment 8

[Brian Ostrom]

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

Comment 9

[Eli Goldberg]

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