560582 - compilation errors with PR_STATIC_ASSERT when building mozilla-central with system NSPR

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Octoploid]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7
Build Identifier: 

Trunk build fails with gcc 4.5.0 on linux.

/var/tmp/yaourt-tmp-markus/aur-firefox-pgo-minefield-smp/firefox-pgo-minefield-smp/src/mozilla-central/content/svg/content/src/nsSVGElement.cpp:104:17: error: expected constructor, destructor, or type conversion before ‘(’ token
/var/tmp/yaourt-tmp-markus/aur-firefox-pgo-minefield-smp/firefox-pgo-minefield-smp/src/mozilla-central/content/svg/content/src/nsSVGElement.cpp: In member function ‘void nsSVGElement::UpdateAnimatedContentStyleRule()’:
/var/tmp/yaourt-tmp-markus/aur-firefox-pgo-minefield-smp/firefox-pgo-minefield-smp/src/mozilla-central/content/svg/content/src/nsSVGElement.cpp:1261:14: warning: unused variable ‘rv’
make[7]: *** [nsSVGElement.o] Error 1


Reproducible: Always

Comment 1

[Boris Zbarsky [:bzbarsky]]

Are you building with system NSPR or something?

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to comment #0)
> error: expected constructor, destructor, or type conversion before ‘(’ token

This points to this line:
  104 PR_STATIC_ASSERT(sizeof(void*) == sizeof(nsnull));

Sounds like the "PR_STATIC_ASSERT" there isn't being understood.
Octoploid: does it help if you add "#include prtypes.h" at the top of nsSVGElement.cpp?

> In member function ‘void nsSVGElement::UpdateAnimatedContentStyleRule()’:
> /var/tmp/yaourt-tmp-markus/aur-firefox-pgo-minefield-smp/firefox-pgo-minefield-smp/src/mozilla-central/content/svg/content/src/nsSVGElement.cpp:1261:14:
> warning: unused variable ‘rv’

This is ignorable (but would be nice to fix) -- it's a variable that only gets used in a NS_ABORT_IF_FALSE (i.e. debug-only).   Octoploid must be doing an opt build.

Comment 3

[Robert Longson [:longsonr]]

If he needs to add prtypes.h then he's almost certainly doing a system NSPR build. He'll just have to build with the in-tree nspr till a new system NSPR version is released.

Comment 4

[Octoploid]

Building with in-tree nspr solved the problem.
Thank you guys.

Comment 5

[Daniel Holbert [:dholbert]]

Yay, glad that worked! Correcting resolution to INVALID, since this wasn't due to a bug in Mozilla code. ("FIXED" would indicate that a patch was committed to the Mozilla codebase to fix the problem.)

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch to update configure test

So we should have configure tests for this sorts of things so that configure explains what the problem is, rather than letting people hit a build error.

It turns out we actually already *do* have a configure test for this particular feature.  This patch updates that test to reflect that we now depend on PR_STATIC_ASSERT being in prtypes.h.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I tested that:
 * without this patch, I can configure --with-system-nspr
 * with it, I get the error --with-system-nspr
 * with it, I can still configure with in-tree nspr

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://hg.mozilla.org/mozilla-central/rev/ffd7972bab5f

configure will now give an error when your system NSPR isn't new enough.

Comment 10

[Jory A. Pratt [:anarchy]]

http://hg.mozilla.org/mozilla-central/file/ffd7972bab5f/configure.in#l4552

We need to actually make use of it and update it to error earlier if the correct version of nspr is not installed. I will attach the patch in just a minute.

Comment 11

[Jory A. Pratt [:anarchy]]

Attachment: check for correct version of nspr

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

See also the discussion in bug 567620.