377344 - Configure should check for PR_STATIC_ASSERT support when building with system NSPR

Status: RESOLVED FIXED

(Firefox Build System :: General, enhancement)

Description

[Caio Tiago Oliveira (asrail)]

GCC 4.1.2 gives this error:

../../../dist/include/xpcom/nsExpirationTracker.h: In constructor
‘nsExpirationTracker<T, K>::nsExpirationTracker(PRUint32)’:
../../../dist/include/xpcom/nsExpirationTracker.h:109: error: there are no
arguments to ‘PR_STATIC_ASSERT’ that depend on a template parameter, so a
declaration of ‘PR_STATIC_ASSERT’ must be available
../../../dist/include/xpcom/nsExpirationTracker.h:109: error: (if you use
‘-fpermissive’, G++ will accept your code, but allowing the use of an
undeclared name is deprecated)


See: http://gcc.gnu.org/onlinedocs/gcc/Name-lookup.html


This is a regression from bug 376568.

Comment 1

[Jeff Walden [:Waldo]]

Something wacky's going on here.  GCC doesn't seem to recognize that PR_STATIC_ASSERT is a macro, so it thinks it's a function and complains that it's not defined (since the argument to the macro doesn't depend on instantiation types for nsExpirationTracker, you can determine this without instantiating nsExpirationTracker).

It's almost as if the prerror.h include isn't being recognized, but a failed #include is an error -- right?  Actually, maybe that's what it is -- what NSPR do you have pulled?  Static assertion support is barely weeks old, so maybe you've got an old version checked out that doesn't define PR_STATIC_ASSERT.

In any case, I'm pretty sure this isn't a GCC >3.4 error, as evidenced by the following successful build (note the GCC version is 4.1.2):

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1176416700.21139.gz&fulltext=1

Comment 2

[Caio Tiago Oliveira (asrail)]

Sorry for taking too long to reply.
I had some issues building nspr in an objdir, so I decided to walk through and be able to build it without system nspr before replying.

Yeah... the issue was the version of nspr, sorry for the noise.

Comment 4

[:Mook]

Umm, if configure.in supports using system NSPR, shouldn't it then check that it can actually use that system NSPR?

Morphing into check to make sure system NSPR is a high enough version.

As far as I can tell though, there has been no NSPR release that includes this yet (it's on NSPR trunk + NSPRPUB_PRE_4_2_CLIENT_BRANCH but not any release; IIRC that branch is just "what Mozilla is using"?).

As I understand it, configure currently looks for NSPR 4.0.0 minimum.

Comment 6

[:Mook]

Attachment: configure check for PR_STATIC_ASSERT

I'm still pretty clueless around autoconf, so I'm not sure if this is correct (I just think it is).  At the very least, when trying to use a system NSPR that doesn't support PR_STATIC_ASSERT, it dies as it should...  (I don't have a system NSPR that does have it, nor do I know how to go about creating one)

Comment 7

[Benjamin Smedberg]

Comment on attachment 266957 [details] [diff] [review]
configure check for PR_STATIC_ASSERT

I don't think you need AC_TRY_LINK, you should just use AC_TRY_COMPILE (and then you don't need to modify LIBS, just CFLAGS).

Comment 8

[:Mook]

Actually, I *do* need AC_TRY_LINK - otherwise gcc happily assumes it's some random function that you forgot to declare.  (By default, one that returns int.)

Yes, that sucks.

Comment 9

[Bernhard Rosenkraenzer]

Calling a random undeclared function is valid C, but not valid C++ -- untested, but this should be a better fix:

AC_LANG_PUSH([C++])
(your stuff here, with AC_TRY_COMPILE)
AC_LANG_POP

Comment 10

[:Mook]

Attachment: use #ifndef/#error/#endif instead

Use the preprocessor to test things instead; this should not care if it's C/C++/whatever, since PR_STATIC_ASSERT is a macro.

Comment 11

[Kenneth Herron]

"use #ifndef/#error/#endif instead" patch checked in. Clearing checkin-needed status.

Comment 12

[:Mook]

forgot to close this - patch was checked in, configure should actually complain now.