Closed
Bug 306334
Opened 19 years ago
Closed 19 years ago
XULRunner debug doesn't link on mac
Categories
(Toolkit Graveyard :: XULRunner, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.8beta4
People
(Reporter: benjamin, Assigned: benjamin)
References
Details
(Keywords: fixed1.8)
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
brendan
:
first-review+
darin.moz
:
second-review+
cbeard
:
approval1.8b4+
brendan
:
approval1.8b5+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 2•19 years ago
|
||
Attachment #194187 -
Flags: first-review?(shaver)
Assignee | ||
Comment 3•19 years ago
|
||
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)
Assignee | ||
Updated•19 years ago
|
Flags: blocking1.8b4+
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta4
Comment 5•19 years ago
|
||
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+
Assignee | ||
Comment 6•19 years ago
|
||
Bah, this doesn't actually work: nsDebug.h is needed, which is a C++ header. Slightly more involved patch coming up.
Assignee | ||
Comment 7•19 years ago
|
||
Attachment #194187 -
Attachment is obsolete: true
Attachment #194311 -
Flags: second-review?(darin)
Attachment #194311 -
Flags: first-review?(brendan)
Comment 8•19 years ago
|
||
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 9•19 years ago
|
||
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+
Assignee | ||
Comment 10•19 years ago
|
||
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?
Assignee | ||
Updated•19 years ago
|
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 11•19 years ago
|
||
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?
Assignee | ||
Comment 12•19 years ago
|
||
Extra bustage fix: we didn't want NS_HIDDEN_() in the nsDebug.h declarations, only NS_COM_GLUE (the two are incompatible).
Updated•19 years ago
|
Attachment #194311 -
Flags: approval1.8b4? → approval1.8b4+
Updated•19 years ago
|
Status: RESOLVED → VERIFIED
Updated•9 years ago
|
Product: Toolkit → Toolkit Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•