Closed Bug 1093069 Opened 10 years ago Closed 10 years ago

Firefox fails to build with system nss - missing prtypes.h header

Categories

(Core :: Security: PSM, defect)

35 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: stransky, Unassigned)

Details

Attachments

(1 file)

Attached patch patchSplinter Review
PRBool definition is missing in OCSPCache.h when build with system nss.
Attachment #8515969 - Flags: review?(kaie)
Martin, what version of Firefox are you trying to build? Your patch references mozilla-release, which would now be 33. Also, what version of NSS does your system have?
Flags: needinfo?(stransky)
Component: Security → Security: PSM
Hi, Yes, the patch is for Firefox 33. But the same problem is with latest trunk - but it needs more changes. My nss is nss-3.17.2-1.fc20.x86_64 (Fedora 20 one).
Flags: needinfo?(stransky)
To be clear, we use this patch in Fedora to ship Firefox 33 with system nss/nspr.
I successfully build firefox 33 with system nspr/nss on debian with no patch.
Also note that prtypes.h includes have been removed on purpose, and adding them back should be frown upon.
Finally, what exactly is your build failure message?
Latest trunk with system nss gives me: gmake[5]: Entering directory `/home/komat/tmp675-trunk-try/src/objdir/security/certverifier' c++ -o Unified_cpp_certverifier0.o -c -I../../dist/stl_wrappers -I../../dist/system_wrappers -include /home/komat/tmp675-trunk-try/src/config/gcc_hidden.h -DSTATIC_EXPORTABLE_JS_API -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DMOZ_GLUE_IN_PROGRAM -DAB_CD=en-US -DNO_NSPR_10_SUPPORT -I/home/komat/tmp675-trunk-try/src/security/certverifier -I. -I/home/komat/tmp675-trunk-try/src/security/certverifier/../manager/boot/src -I/home/komat/tmp675-trunk-try/src/security/certverifier/../manager/ssl/src -I/home/komat/tmp675-trunk-try/src/security/certverifier/../pkix/include -I../../dist/include -I/usr/include/nspr4 -I/usr/include/nss3 -I/usr/include/pixman-1 -fPIC -DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MP -MF .deps/Unified_cpp_certverifier0.o.pp -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -freorder-blocks -Os -fomit-frame-pointer -Wall /home/komat/tmp675-trunk-try/src/objdir/security/certverifier/Unified_cpp_certverifier0.cpp In file included from ../../dist/system_wrappers/hasht.h:3:0, from /home/komat/tmp675-trunk-try/src/security/certverifier/OCSPCache.h:28, from /home/komat/tmp675-trunk-try/src/security/certverifier/CertVerifier.h:11, from /home/komat/tmp675-trunk-try/src/security/certverifier/CertVerifier.cpp:7, from /home/komat/tmp675-trunk-try/src/objdir/security/certverifier/Unified_cpp_certverifier0.cpp:2: /usr/include/nss3/hasht.h:48:29: error: ‘PRBool’ has not been declared void (*destroy)(void *, PRBool); ^ gmake[5]: *** [Unified_cpp_certverifier0.o] Error 1
The first line in hasht.h is #include "prtypes.h"
(In reply to Mike Hommey [:glandium] from comment #8) > The first line in hasht.h is #include "prtypes.h" I see, it was added by Bug 858231. I wonder why we have old headers in Fedora. Anyway, thanks for help with that.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Due to glibc build breakage, in fedora we had to patch hasht.t to not include prtypes.h and add another patch to include it from pkcssig.c as hasht.h didn't any loger. Patch2: hasht-dont-include-prtypes.patch Patch3: pkcs1sig-include-prtypes.patch Looking at the nss-util.spec I see: * Fri Apr 19 2013 Elio Maldonado <emaldona@redhat.com> - 3.15-0.1.beta1.2 - Don't include prtypes.h from hasht.t - Resolves: rhbz#953277 - rawhide build of glibc fails due to fatal error from nss3/hasht.h The bug in question is https://bugzilla.redhat.com/show_bug.cgi?id=953277 This is not an issue on debian because there glibc doesn't depend on nss-softoken-freebl as it does on fedora/rhel/centos and other rhel/fedora derived distributions. That's because glibc's tiny hash library links with our code in order to get FIPS 140 validation.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: