Closed Bug 306334 Opened 19 years ago Closed 19 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) (deleted) — 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: 19 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: