383866 - Cuurrent CVS (3.0a5) build fails with --with-system-nss

Status: RESOLVED INCOMPLETE

(Firefox Build System :: General, defect)

Description

[Robert Bradbury]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3) Gecko/20070427 Firefox/3.0a3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3) Gecko/20070427 Firefox/3.0a5

Building a fully (or mostly) static Firefox (minimal .so files) is difficult with the current Mozilla system.  One can get close to that if one loads the archive (.a) files in the proper order.  The NSS library is problematic however due to the way certificate construction/verification gets integrated into the library build process.  (I will admit that I do not understand this process.) One strategy to avoid this problem is to build Firefox using only the system NSS .so libraries (e.g. --with-system-nss).

Using this flag with modified nss sources (as the current CVS is) without having installed the new header files results in compilation failures in at least nsNSSComponent.c and perhaps other recently modified files.

Errors include:
nsNSSComponent.cpp: In function 'void setOCSPOptions(nsIPrefBranch*)':
nsNSSComponent.cpp:998: error: 'ocspMode_FailureIsVerificationFailure' was not declared in this scope
nsNSSComponent.cpp:998: error: 'CERT_SetOCSPFailureMode' was not declared in this scope
nsNSSComponent.cpp:1001: error: 'ocspMode_FailureIsNotAVerificationFailure' was not declared in this scope
nsNSSComponent.cpp:1001: error: 'CERT_SetOCSPFailureMode' was not declared in this scope
nsNSSComponent.cpp: In function 'nsresult setPassword(PK11SlotInfo*, nsIInterfaceRequestor*)':
nsNSSComponent.cpp:2494: warning: dereferencing type-punned pointer will break strict-aliasing rules

This is a problem with compilation rules:
1) Why is nsNSSComponent.cpp being compiled if I have selected --with-system-nss?
2) There is confusion between --with-system-nss being a compile-time vs. a link-time option.  I.e. New library sources, e.g. nsNSSComponent.cpp should *always* be compiled with the build specific header files (-I../../../../dist/public/nss) [or even less "distant" in the source tree paths]) and not the system header files (-I/usr/include/nss) which are only appropriate for whatever source version was used for compiling the system shared libraries (/usr/lib/nss).

When I specify --with-system-nss however the executable should reference thye system shared libraries (/usr/lib/nss/lib*.so*).

I believe there may be a similar problem with referencing the system headers (in /usr/include/nspr) when using --with-system-nspr vs. --without-system-nspr.

Compiling release specific source files should always use the release specific header files.


Reproducible: Always

Steps to Reproduce:
1. Download completely fresh CVS tree (with sources changed on 29-30 May 2007 or later).
2. Setup build flags with --with-system-nss
3. Attempt to build Firefox.
Actual Results:  
Source file compilation fails in recently modified security/manager/ssl/src components.

Expected Results:  
Firefox should compile sources and load firefox-bin.

Comment 1

[Robert Bradbury]

The problem is in the setup of config/autoconf.mk, in particular the settings of NSS_CFLAGS and NSPR_CFLAGS and whether one gets:
NSPR_CFLAGS= -I/usr/include/nspr OR -I../../../../dist/public/nspr
NSS_CFLAGS=  -I/usr/include/nss  OR -I../../../../dist/public/nss

If the nss libraries or the nspr libraries require "new" header files to compile, the compilations will always fail with the "-with-system-nss/nspr" configuration options, unless one *pre-installs* the new header files into the system locations *before* attempting to compile Mozilla/Firefox.  It can be argued that the NSS/NSPR_CFLAGS options should *never* be using the system libraries (/usr/include) when compiling the Mozilla source (e.g. --enable-application=browser).  Whether one might want the flags configured differently when one only has a subset of the sources that do not include the nss/nspr sources is open to debate.

There may be a distinct problem as to *why* files in security/manager/ssl/... are being compiled *at all* when "--with-system-nss" is in effect.  The same would apply to files under nsprpub/... when "--with-system-nspr" is in effect.

Comment 2

[Benjamin Smedberg]

It sounds like you're trying to compile mozilla against an older NSS. Also, you obviously don't understand the difference between PSM (security/manager, part of mozilla) and NSS (a standalone project). If there is a bug here, it is that our configure checks don't enforce that the system NSS is new enough.