Closed Bug 1704903 Opened 2 years ago Closed 1 year ago

PR_STATIC_ASSERT causes NSS build failures on GCC 11


(NSPR :: NSPR, defect)



(Not tracked)



(Reporter: bdk, Unassigned)




(1 file)

Attached file build-output.txt

I'm having issues building NSS using GCC 11 using the instructions from this page:

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/

I'm running Fedora 34 beta.

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.

Assignee: nobody → nobody
Component: Build → NSPR
OS: Unspecified → All
Product: NSS → NSPR
Hardware: Unspecified → All
Target Milestone: --- → 4.31
Version: trunk → 4.30
Summary: NSS not building on GCC 11 → PR_STATIC_ASSERT causes NSS build failures on GCC 11

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

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?

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.

Two things: 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.

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.

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

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

Closed: 1 year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.