Last Comment Bug 101965 - NSS forte 6 build contains workshop 4 and 5 objects
: NSS forte 6 build contains workshop 4 and 5 objects
Product: NSS
Classification: Components
Component: Build (show other bugs)
: 3.3.1
: Sun Solaris
P1 blocker (vote)
: 3.3.1
Assigned To: Sonja Mirtitsch
: Sonja Mirtitsch
Depends on:
  Show dependency treegraph
Reported: 2001-09-27 11:00 PDT by Sonja Mirtitsch
Modified: 2001-10-10 10:51 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

build log (202.81 KB, text/plain)
2001-09-27 11:03 PDT, Sonja Mirtitsch
no flags Details

Description User image Sonja Mirtitsch 2001-09-27 11:00:12 PDT
I tried to do this build, it failed because it does not import DBM:

the lines I added to the init files were:

$ENV{IMPORTS}='nspr20/v4.1.2/forte6 dbm/DBM_1_55_RTM/forte6';
$IMPORTS='nspr20/v4.1.2/forte6 dbm/DBM_1_55_RTM/forte6';

which had no effect
$Commands{gmake,parameters}  = 'IMPORTS=nspr20/v4.1.2/forte6
(above is one line, nspr and dbm are seperated by a blank

Why can't we put a real fix into the file or in coreconf? 

The build failure:

gmake[2]: Entering directory
cc -o SunOS5.8_DBG.OBJ/jarver.o -c -g -KPIC -DSVR4 -DSYSV -D__svr4 -D__svr4__
-I/usr/openwin/include -I../../../../dist/SunOS5.8_DBG.OBJ/include 
-I../../../../dist/public/security -I../../../../dist/private/security
-I../../../../dist/public/security -I../../../../dist/public/dbm  jarver.c
"../../../../dist/private/security/cdbhdl.h", line 43: gmake[2]: Leaving
cannot find include file: "mcom_db.h"
"../../../../dist/private/security/cdbhdl.h", line 50: syntax error before or at: DB
"../../../../dist/private/security/cdbhdl.h", line 50: cannot recover from
previous errors
cc: acomp failed for jarver.c
gmake[2]: *** [SunOS5.8_DBG.OBJ/jarver.o] Error 2
gmake[1]: *** [libs] Error 2
gmake: *** [libs] Error 2 

---- paste in Wan-Teh's email

Chris Elving of the iWS team pointed out to me that
the forte6 builds of NSS 3.3 and 3.3.1 (Beta) contain
objects compiled by WorkShop 4.2 or 5.0 on Solaris 2.6.

(Daniel, I am bringing this issue to your attention
since iDS 5.1 is using NSS 3.3 and I understand that
Solaris 9 integration requires that iDS 5.1 be
compiled on Solaris 8.)

This can be shown with these commands:
% cd
% strings -a * | grep WorkShop | grep 4.2
% strings -a * | grep WorkShop | grep 5.0

I believe this is caused by NSS being linked with
the non-forte6 versions of NSPR and DBM static
libraries (libplds4.a, libplc4.a, and libdbm.a).

The best solution is to modify the "init" file
so that it invokes the nss_RelEng_bld makefile
target with
  IMPORTS='nspr20/v4.1.2/forte6 dbm/DBM_1_55_RTM/forte6'
on the command line.  (The value of IMPORTS needs to be
quoted.)  This will override the value of IMPORTS in

A simpler but less reproducible solution is to
check out the source tree first, and then manually
edit the value of IMPORTS in mozilla/security/nss/
Comment 1 User image Sonja Mirtitsch 2001-09-27 11:03:43 PDT
Created attachment 51089 [details]
build log
Comment 2 User image Sonja Mirtitsch 2001-09-27 15:54:21 PDT
$Commands{gmake,parameters}  = 'IMPORTS=\'nspr20/v4.1.2/forte6
dbm/DBM_1_55_RTM/forte6\''; worked, I checked the tip build with 
strings * | grep -i workshop | grep -v "WorkShop 6"
I am rebuilding NSS 3.3 right now, as soon as it is done I will run QA on it,
and then push it to the integration area.
Most likely soon afterwards it is going to be pushed to /s/b/c, it is not clear
yet if the existing NSS 3.3 RTM forte6 directory can just be replaced.
Comment 3 User image Sonja Mirtitsch 2001-10-10 10:51:02 PDT
has been fixed

Note You need to log in before you can comment on or make changes to this bug.