native-libpng builds compile with Mozilla libpng header files

VERIFIED INVALID

Status

()

defect
P3
normal
VERIFIED INVALID
20 years ago
20 years ago

People

(Reporter: newt, Assigned: briano)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: when native libs are linked, dist/includes are used instead of native includes.)

Reporter

Description

20 years ago
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

20 years ago
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.
Reporter

Comment 2

20 years ago
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).

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 3

20 years ago
I'm on it.
-pn

Comment 4

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

Updated

20 years ago
Assignee: pnunn → cyeh
Status: ASSIGNED → NEW
Whiteboard: when native libs are linked, dist/includes are used instead of native includes.

Comment 5

20 years ago
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.
Assignee

Updated

20 years ago
Assignee: cyeh → briano
Target Milestone: M6
Assignee

Comment 6

20 years ago
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.... ;-)
Assignee

Updated

20 years ago
Status: NEW → ASSIGNED
Reporter

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → INVALID
Reporter

Comment 7

20 years ago
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.
Assignee

Comment 8

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

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 9

20 years ago
Rubber-stamping Verified/Invalid, since Briano Is Always Right. (tm)
You need to log in before you can comment on or make changes to this bug.