Closed Bug 306334 Opened 21 years ago Closed 20 years ago

XULRunner debug doesn't link on mac

Categories

(Toolkit Graveyard :: XULRunner, defect, P1)

PowerPC
macOS
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.8beta4

People

(Reporter: benjamin, Assigned: benjamin)

References

Details

(Keywords: fixed1.8)

Attachments

(1 file, 1 obsolete file)

XULRunner debug doesn't link on mac because of the use of PR_Assert in pldhash.c... replace this usage with NS_ASSERTION, which will link.
Is this because we're using a non-debug NSPR with a debug XPCOM? Is that a supported configuration? (Or are we finding the Apple-shipped NSPR and being confused by that?) There are other PR_ASSERT references in the tree, like in the XML content sink, libjar, etc: http://lxr.mozilla.org/mozilla/search?string=PR_ASSERT . Those are probably easy enough to fix if we decide that this is what we want to do, but I'm not clear on why this is a problem for XULRunner but not, say, Firefox. Finally, pldhash.c is generated from jsdhash.c, so you'll need to change js/src/plify_jsdhash.sed and regenerate in order to do this, should it indeed be the right thing.
Attached patch s/JS_ASSERT/NS_ASSERTION/ (obsolete) — Splinter Review
Attachment #194187 - Flags: first-review?(shaver)
No, this is because the XPCOM glue cannot depend on NSPR.
Comment on attachment 194187 [details] [diff] [review] s/JS_ASSERT/NS_ASSERTION/ OK, I guess that's fair. plify_jsdhash is brendan's baby, though; -> him.
Attachment #194187 - Flags: first-review?(shaver) → first-review?(brendan)
Flags: blocking1.8b4+
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta4
Comment on attachment 194187 [details] [diff] [review] s/JS_ASSERT/NS_ASSERTION/ Cool -- but you might even match PR_ASSERT(0) and turn that into NS_NOTREACHED or some such. /be
Attachment #194187 - Flags: first-review?(brendan) → first-review+
Bah, this doesn't actually work: nsDebug.h is needed, which is a C++ header. Slightly more involved patch coming up.
Attachment #194187 - Attachment is obsolete: true
Attachment #194311 - Flags: second-review?(darin)
Attachment #194311 - Flags: first-review?(brendan)
Comment on attachment 194311 [details] [diff] [review] Use NS_ASSERTION, and make nsDebug.h use C symbols instead of C++ r=me, looks fine (only thought is to include XPCOM in the prefix, in addition to or instead of the Glue or even the NSGlue in NSGlue_ -- but xpcom probably has a consistent prefixing scheme in place; ignore me if this follows that). /be
Attachment #194311 - Flags: first-review?(brendan) → first-review+
Comment on attachment 194311 [details] [diff] [review] Use NS_ASSERTION, and make nsDebug.h use C symbols instead of C++ r=darin
Attachment #194311 - Flags: second-review?(darin) → second-review+
Comment on attachment 194311 [details] [diff] [review] Use NS_ASSERTION, and make nsDebug.h use C symbols instead of C++ Landed on trunk, this is very low risk.
Attachment #194311 - Flags: approval1.8b5?
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment on attachment 194311 [details] [diff] [review] Use NS_ASSERTION, and make nsDebug.h use C symbols instead of C++ If it's very low risk (and I agree it is), why not for b4? /be
Attachment #194311 - Flags: approval1.8b5?
Attachment #194311 - Flags: approval1.8b5+
Attachment #194311 - Flags: approval1.8b4?
Extra bustage fix: we didn't want NS_HIDDEN_() in the nsDebug.h declarations, only NS_COM_GLUE (the two are incompatible).
Attachment #194311 - Flags: approval1.8b4? → approval1.8b4+
Status: RESOLVED → VERIFIED
Fixed on 1.8 branch.
Keywords: fixed1.8
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: