|Version 9 (modified by 4 years ago) ( diff ),|
The testsuite in modern versions of nss
The current testsuite is designed to catch regressions in new additions, so every new addition should come with one or more tests (I noticed from the diff between 3.40 and 3.40.1 that there were tests, although the book said there was not a testsuite).
Unfortunately, it needs to be run with nspr and nss directories side by side in the top-level directory (which is how combined nspr+nss tarballs present things), and built unoptimized (BUILD_OPT=0).
For further details, see https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Sources_Building_Testing
I managed to get that process working on nss-3.40-with-nspr-4.20 but not with 3.40.1.
make -C nss nss_build_all USE64=1
That took almost 25 minutes, I don't think the particular CPU makes a lot of difference. For that run, 6 tests failed (look for ' FAILED' in the output), all reporting that a peer's certificate has expired.
Unless you intend to hack on nss/nspr, running the tests on a released version is not recommended.
Old notes, retained in case still useful
On ppc64, building 32-bit barfs on -z defs when CC is overridden to "gcc -m32". Use the patch at http://www.linuxfromscratch.org/patches/downloads/nss/nss-3.11-zdefs-1.patch and read the instructions in it.
Test Suite: CRL tests
cert.sh uses the local time when creating revocation lists. This can cause a number of tests (130 out of 800) to fail.
cd mozilla/security/nss/tests/cert/ && sed 's/date "*+%Y%m%d%H%M%SZ"*/date -u "+%Y%m%d%H%M%SZ"/g' < cert.sh \ > cert.sh.tmp && mv cert.sh.tmp cert.sh
NSS is unlikely to compile with MAKEFLAGS set to "-j 2". The build process relies on files that it creates for itself very early in the process, so make sure to turn off multi-threaded builds for this one (though it is not recommended that you use the "-j 2" option at all).