1704903 - PR_STATIC_ASSERT causes NSS build failures on GCC 11

Status: RESOLVED FIXED

(NSPR :: NSPR, defect)

Description

[Ben Dean-Kawamura [:bdk]]

Attachment: build-output.txt

I'm having issues building NSS using GCC 11 using the instructions from this page: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Building

I don't think GCC 11 has been officially released, but it should be soon. It looks to me that the issue is the new -Warray-parameter warning. I'm attaching the output of ./nss/build.sh.

I'm running Fedora 34 beta.

Comment 1

[Martin Thomson [:mt:]]

This is something that NSPR can fix. We can test for the presence of _Static_assert, which is in most versions of GCC that we need to support (it was added in 4.6; NSS uses 4.4 though). It's c11, which we can't outright require, but it should be easy to detect and compile in.

Comment 2

[Ben Dean-Kawamura [:bdk]]

nss-3.66 is building for me with GCC 11. I think this one could be closed, but there seems to be one last cleanup: delete the #define in nspr/pr/include/prtypes.h

Comment 3

[Martin Thomson [:mt:]]

It sounds like GCC changed, because I still see this:

#define PR_STATIC_ASSERT(condition) \
    extern void pr_static_assert(int arg[(condition) ? 1 : -1])

Are you suggesting we remove that Ben?

Comment 4

[Ben Dean-Kawamura [:bdk]]

That's there, but it's just a #define. For older versions of NSS I saw a lot of uses of that define. It seems like someone replaced those with something else and the last step is to remove the #define.

Comment 5

[Martin Thomson [:mt:]]

Two things:

https://searchfox.org/nss/search?q=PR_STATIC_ASSERT&path= indicates that this has lots of use (which is why I suspect that GCC changed).

And we can't remove things from the NSPR API without affecting backward compatibility. We would need to replace it.

Comment 6

[Ben Dean-Kawamura [:bdk]]

Sorry, rg was confusing me, you're right about it still being used. I think you're also right about the GCC change, since I was getting a build error before and now it's working.

Comment 7

[Mike Hommey [:glandium]]

Also note we now have a CI job that builds Firefox with GCC 11, and it doesn't hit this problem.

Comment 8

[Ben Dean-Kawamura [:bdk]]

I think this one can be safely closed now. Building is working and that cleanup step that I suggested doesn't make sense.