Version-Release number of selected component (if applicable): nspr-devel-4.7.0.99.2-1.el5 for test case and patch see original bug +++ This bug was initially created as a clone of Bug #451616 +++ Description of problem: Using nspr header gives a warning in the prlink.h file when -Wstrict-prototypes is included in the CFLAGS. And when -Werror is used, then it is not possible to compile at all. Version-Release number of selected component (if applicable): nspr-devel-4.6.7-3.fc8 but the header was not changed since Apr/06/2006, so all current Fedora and RHEL versions are affected. How reproducible: 100% Steps to Reproduce: 1. run the script from attachments Actual results: In file included from /usr/include/nspr4/nspr.h:55, from nspr-test.c:2: /usr/include/nspr4/prlink.h:52: warning: function declaration isn’t a prototype /usr/include/nspr4/prlink.h:209: warning: function declaration isn’t a prototype Expected results: No warnings Additional info: There was a thread in gcc mailing list about the meaning of the warning - http://gcc.gnu.org/ml/gcc-help/2006-07/msg00033.html -- Additional comment from dan on 2008-06-16 04:04 EST -- Created an attachment (id=309468) test case -- Additional comment from dan on 2008-06-16 04:08 EST -- Created an attachment (id=309471) patch to remove the warnings
This bug is preventing us building cluster packages for RHEL5. I don't see why we should have to change our compiler flags to work around a bug in a library. Especially as it seems to have been recently (re)introduced.
(In reply to comment #1) > This bug is preventing us building cluster packages for RHEL5. It's just a warning, do you abort your builds for any warnings? > I don't see why > we should have to change our compiler flags to work around a bug in a library. > Especially as it seems to have been recently (re)introduced. The upstream bug has been proposed as WONTFIX. Upstream is worried this patch may break source compatibility. Either we ignore this warning or we must carry a patch in the NSPR package.
Created attachment 408383 [details] Build output This is a typescript output of building cman (specifically fence_xvm part, which uses nss/nspr) with gcc-4.1.2-48.el5 from RHEL 5.5 Build 1: - older nss/nspr from 5.4 installed (WORKS) Build 2: - newer nspr installed from http://rhn.redhat.com/errata/RHSA-2010-0165.html (WORKS) Build 3: - newer nss installed from http://rhn.redhat.com/errata/RHSA-2010-0165.html (FAILS) I looked at prlink.h - historically, the function pointer has been that way for many years. I think this is not a new bug in nspr, but it was made visible by a change in nss with the update from nss-3.12.3.99.3-1.el5_3.2 to nss-3.12.6-1.el5_4.x86_64.rpm. If I had to guess, I would suppose the #includes in nss changed.
In Bug 451616 the following fix has been proposed for the the nspr header wich has function protopyes which aren't strict ansi. --- prlink.h.orig 2008-06-16 09:33:28.000000000 +0200 +++ prlink.h 2008-06-16 09:33:58.000000000 +0200 @@ -49,7 +49,7 @@ typedef struct PRStaticLinkTable { const char *name; - void (*fp)(); + void (*fp)(void); } PRStaticLinkTable; /* @@ -206,7 +206,7 @@ ** ** This function does not modify the reference count of the library. */ -typedef void (*PRFuncPtr)(); +typedef void (*PRFuncPtr)(void); NSPR_API(PRFuncPtr) PR_FindFunctionSymbol(PRLibrary *lib, const char *name); The problem is that if we were to apply this fix we could potentially break existing code and we want to preserve in fedora and RHEL the compatibility guarantees from upstream nss and nspr from upstream.
Created attachment 409322 [details] prevents nspr's prink.h from getting indirectly included by nss clients
An nss scratch build is avaiable at https://brewweb.devel.redhat.com/taskinfo?taskID=2403399
(In reply to comment #8) Ignore this build, it's not good. A corrected patch and build coming next.
Created attachment 409353 [details] Patch V2, secmod doesn't include prlink.h
(In reply to comment #9) New scratch build https://brewweb.devel.redhat.com/taskinfo?taskID=2403527
Those RPMs fix the cluster build.