PSM2: non-debug freebl build fails on Solaris



16 years ago
16 years ago


(Reporter: Rich Burridge, Assigned: Wan-Teh Chang)



Firefox Tracking Flags

(Not tracked)



(5 attachments)



16 years ago
Chris, I've put this one under "Build config" this time, rather than 
NSS or PSM. Please adjust if I'm wrong.

We are trying to build PSM2 with Sun native compilers (Forte 6 Update 1).


% gmake -f checkout BUILD_MODULES=psm2
% gmake -f build_all BUILD_MODULES=psm2

In .../mozilla/security/nss/lib/freebl/SunOSpure32
when it tries to build, the following occurs:

ld -G -h -B symbolic -z defs -z now -z text -M
mapfile.Solaris -o SunOS5.8_OPT.OBJ/
SunOS5.8_OPT.OBJ/ldvector.o SunOS5.8_OPT.OBJ/prng_fips1861.o
SunOS5.8_OPT.OBJ/sha_fast.o SunOS5.8_OPT.OBJ/md2.o SunOS5.8_OPT.OBJ/md5.o
SunOS5.8_OPT.OBJ/alg2268.o SunOS5.8_OPT.OBJ/arcfour.o SunOS5.8_OPT.OBJ/arcfive.o
SunOS5.8_OPT.OBJ/desblapi.o SunOS5.8_OPT.OBJ/des.o SunOS5.8_OPT.OBJ/rijndael.o
SunOS5.8_OPT.OBJ/dh.o SunOS5.8_OPT.OBJ/pqg.o SunOS5.8_OPT.OBJ/dsa.o
SunOS5.8_OPT.OBJ/rsa.o SunOS5.8_OPT.OBJ/mpprime.o SunOS5.8_OPT.OBJ/mpmontg.o
SunOS5.8_OPT.OBJ/mplogic.o SunOS5.8_OPT.OBJ/mpi.o  
-L../../../../../dist/SunOS5.8_OPT.OBJ/lib/ -lplc4 -lplds4 -lnspr4 -lc
Undefined           first referenced
 symbol                 in file
s_mpv_mul_d                         SunOS5.8_OPT.OBJ/mpmontg.o
conv_i32_to_d32_and_d16             SunOS5.8_OPT.OBJ/mpmontg.o
s_mpv_mul_d_add                     SunOS5.8_OPT.OBJ/mpi.o
mont_mulf_noconv                    SunOS5.8_OPT.OBJ/mpmontg.o
s_mpv_mul_d_add_prop                SunOS5.8_OPT.OBJ/mpmontg.o
conv_i32_to_d32                     SunOS5.8_OPT.OBJ/mpmontg.o
conv_i32_to_d16                     SunOS5.8_OPT.OBJ/mpmontg.o
ld: fatal: Symbol referencing errors. No output written to
gmake[5]: *** [SunOS5.8_OPT.OBJ/] Error 1
gmake[5]: Leaving directory

According to Margaret Chan, if f you are building with debug enabled
then this problem doesn't occur. 

I've done a bit of research on this (and will continue to look at it).

Now if we remove the following from the
...mozilla/security/nss/lib/freebl/Makefile (at about line 164):
-ifdef USE_64
-# this builds for Sparc v9a pure 64-bit architecture
-    MPI_SRCS += mpi_sparc.c
-    ASFILES   = mpv_sparcv9.s montmulfv9.s
-#   MPI_SRCS += mpv_sparc.c
-# removed -xdepend from the following line
-    SOLARIS_FLAGS = -fast -xO5 -xrestrict=%all -xchip=ultra -xarch=v9a -KPIC
-    SOLARIS_AS_FLAGS = -xarch=v9a -K PIC
-# this builds for Sparc v8+a hybrid architecture, 64-bit registers, 32-bit ABI
-    MPI_SRCS += mpi_sparc.c
-    ASFILES  = mpv_sparcv8.s montmulfv8.s
-    SOLARIS_AS_FLAGS = -xarch=v8plusa -K PIC
-#   ASM_SUFFIX = .S

and do:

% gmake clean
% gmake

those symbols are picked up from ...mozilla/security/nss/lib/freebl/mpi/mpi.c

In mpi.c, each of the routines for the unresolved symbols is surronded by:

So if we don't remove those lines from the .../freebl/Makefile, then 
MP_ASSEMBLY_MULTIPLY is apparently being defined, but the assembly file
isn't. Still investigating this.

Now obviously we would prefer to use the specially crafted assembler 
routine rather than the generic .c routines for performance reasons.

Comment 1

16 years ago
Created attachment 32338 [details]
Transcript of "gmake -p -n"

Comment 2

16 years ago
I've added a transcript of the output of doing a "gmake -p -n" on my build
machine. Hopefully this should tell us why it's failed to build the assembler

Comment 3

16 years ago
Rich, if you're not building the NSS_CLIENT_BRANCH (autoconf branch) of NSS,
then the bugs need to be filed against the NSS product. Sorry.

Assignee: cls → wtc
Component: Build Config → Libraries
Product: Browser → NSS
QA Contact: granrose → sonmi
Version: other → 3.2.1

Comment 4

16 years ago
Chris, fair enough. Perhaps you can still help though.

I think I have an inkling of what's going on here. 

It seems that this Makefile is used twice. First it tries
to build For this, run USE_PURE_32
is not defined, so it follows the #else clause in the
Makefile (about line 168) and it sets ASFILES to the two
assembly files, and DEFINES includes -DMP_ASSEMBLY_MULTIPLY
The two assembler files are compiled, and the library is
built successfully.

Now the second time it uses the Makefile is when it's trying
to build It creates a SunOSpure32 
directory, and a load of symbolic links and sets USE_PURE_32. 

This means that the Makefile takes the #ifdef USE_PURE_32 clause 
at about line 165, and adds three definitions to DEFINES. 
Unfortunately, the old definitions (including -DMP_ASSEMBLY_MULTIPLY) 
appear to still be defined, therefore when it compiles mpi.c, the 
routines that are surronded by #if !defined(MP_ASSEMBLY_MULTIPLY) 
are not compiled, therefore generating unresolved symbols at ld 
build time.

Can you think of a simple fix for this?

Comment 5

16 years ago
Rich, are you able to explain why the debug build does not
have this problem?

Comment 6

16 years ago
In a word, no. Margaret, can you chip in here, as you were the person who
successfully built this?

I've just thought of a potential solution though (haven't tried it yet, 
so I might be talking crap).

What if right at the very top of the .../freebl/Makefile we had:


This would (hopefully) reset the DEFINES definition. I'm going into
a meeting now, but I'll try this in an hour or so and see if it works.

Comment 7

16 years ago
The "DEFINES=" didn't work. Back to the drawing board.
As I understand it, the working hypothesis here is that makefile 
variables from PSM/mozilla makefiles are leaking through into,
and interfereing with, the NSS makes.   Recall that the NSS makes
work OK on Solaris, both OPT and DBG, when not invoked via PSM's
make system.

One way to isolate the two sets of makefile variables is to use a 
shell script.  That is, have psm makefiles invoke a shell script 
that invokes the NSS make, rather than invoking make on the NSS 
makefiles directly.

Variables that need to be passed can be passed explicitly, e.g.
on the command line.

Comment 9

16 years ago
I was building using NSS_CLIENT_BRANCH.  Checking out psm2 by

gmake -f checkout BUILD_MODULES=psm2 

checks out codes from the above branch for me:

% cvs status mpi.c
File: mpi.c             Status: Up-to-date

   Working revision:    1.32
   Repository revision: 1.32   
   Sticky Tag:          NSS_CLIENT_TAG (revision: 1.32)
   Sticky Date:         (none)
   Sticky Options:      (none)

My build with --enable-debug --disable-optimize --enable-modules=psm2 does not
have this problem, but I can't say for sure if this problem is simply triggered
by enabling optimize.  

Checking on Rich's build problem, I kind of feel that the build should not be
going into this section:  ifdef USE_64 as we're not enabling 64 bit, but I have
not figured out where it is being set/defined.

Comment 10

16 years ago
Margaret, were you using NSS_CLIENT_BRANCH or NSS_CLIENT_TAG?

Comment 11

16 years ago
Created attachment 32361 [details]
Transcript of building the freebl library with debug turned on and no build problems.

Comment 12

16 years ago
Created attachment 32362 [details]
Transcript of building the freebl library with no debug and no optimize, which causes the undefined symbols.

Comment 13

16 years ago
I've added two more attachments to the bug. There is a transcript of a
build done by our RE team, with debug turned on (a Solaris 7 SPARC machine).
There are no build errors there, and you will see that -DMP_ASSEMBLY_MULTIPLY
is not defined when compiling the second library. The other attachment is
for the build on my machine, with no debug and no optimization (ie. 
--disable-optimize in .mozconfig which apparantly is ignored). This one
has -DMP_ASSEMBLY_MULTIPLY defined for the builing of the second library.
Where is that coming from? Find, that and I think we can solve this.

Comment 14

16 years ago
Rich, every compile in your second transcript ("no debug and
no optimize", what does that mean?) has this compiler warning:
cc: Warning: multiple use of -K option, previous one discarded.

Many compiler options are repeated on the command line.  Something
is wrong here.

Comment 15

16 years ago
Sorry, clarification:  it was NSS_CLIENT_TAG that psm2 used,  NOT

Comment 16

16 years ago
> ("no debug and no optimize", what does that mean?)

It means I had --disable-debug and --disable-optimize in my .mozconfig.
Having said that, it looks like the libraries are being compiled with -O
so I'm not sure where it's picking this up from.

> has this compiler warning:
> cc: Warning: multiple use of -K option, previous one discarded.
> Many compiler options are repeated on the command line.  Something
> is wrong here.

Yes. This could be related to the problem we are seeing. 

Comment 17

16 years ago
I think that nss & psm can only take one option or the other.  i.e.,
--enable-debug --disable-optimize or --disable-debug --enable-optimize. 
Disabling/Enabling both may confuse the build.  This should not be the problem
though as Shirley & Kevin (our RE)'s builds with --disable-debug
--enable-optimize with optimization level O3 fails the same way.
Created attachment 32377 [details]
Transcript of succesful nightly solaris optimized NSS build
Hopefully the attached log from a succesful nightly optimized NSS build
will show you what the command lines ought to look like.  HTH.
Summary: PSM2: freebl does not build correctly on Solaris when not debug. → PSM2: non-debug freebl build fails on Solaris

Comment 20

16 years ago
Thanks Nelson. Interesting. This is on a 5.6 machine. We should compare
the SunOS5.[6,7,8].mk files to see if there is anything funkily
different there. 

Comment 21

16 years ago
Nelson, could you attach a "gmake -p -n" for a build in the freebl directory
from your Solaris 5.6 machine please? I'd like to compare that with the 
gmake -p -n that I attached for my failed build. Thanks.
Rich, I emailed you the 1/2 megabyte output of "gmake -p -n libs"
Please don't attach it here.

BTW, I build NSS on solaris 6, 7, and 8 all the time.
There shouldn't be any differences between those builds, other than
in the object directory names.  If you find there are other 
differences, please let me know.

Comment 23

16 years ago
OK, I think I have tracked down this bug.

Rich: I bet that you have the environment variable CFLAGS set.  You can
try unsetting CFLAGS and rebuilding.

Nelson: You can try setting the environment variable CFLAGS (for example,
to -O) and you should get the same build failure.

If CFLAGS (actually any make variable) is set in the environment, GNU make
passes the *current value* (which may have been modified by the makefile)
of CFLAGS to sub-makes.  In mozilla/security/coreconf/, we
define CFLAGS with "+=".  So if CFLAGS is set in the environment, sub-makes
will append to the value of CFLAGS in the parent makefile.

If CFLAGS is not set in the environment, GNU make does not pass it to

I am going to attach a fix that defines CFLAGS with "=".

Comment 24

16 years ago
Created attachment 32519 [details] [diff] [review]
Proposed fix.  Define CFLAGS with = as opposed to +=.

Comment 25

16 years ago
wtc: Yes, I did have CFLAGS environment variable set 
(also CXXFLAGS). Am trying a rebuild now (without those
two set, and without your proposed patch), just to confirm 
that this will build. Thanks.

Comment 26

16 years ago
wtc: yes, this was indeed the problem. I unsetenv'ed my
CFLAGS, and the build built just fine. On Monday, I'll
apply your patch, set a CFLAGS, and see if that works
too. Thanks.

Comment 27

16 years ago
Hi Wan-Teh:

In other words, does it mean that by changing it to CFLAGS= as opposed to
CFLAGS+=, it will no longer append the CFLAGS that's set in the environment to
CFLAGS?  Just try to understand it better.  Thanks, Margaret 

Comment 28

16 years ago
Margaret Chan wrote:
> In other words, does it mean that by changing it to CFLAGS= as opposed to
> CFLAGS+=, it will no longer append the CFLAGS that's set in the environment to
> CFLAGS?  Just try to understand it better.

Well, it's actually more complicated than that.  If you want to fully
understand how GNU make behaves in this regard, send me email or give
me a call.

Comment 29

16 years ago
wtc: I've asked our RE team to try out your fix with their builds tonight,
and to update this bug with the results. Hopefully that should be sufficient
to indicate whether the problem has been fixed on not. Thanks.

Comment 30

16 years ago
From Bug #77324:

Given when the bugs were opened I'd say bug #77788 is a duplicate if this one

Anyway - removing CFLAGS and downloading 20010430 has changed the failure mode
for me to:

make[2]: Leaving directory
../../config/nsinstall -R -m 755
../../dist/SunOS5.6_sparc_OPT.OBJ/lib/ ../../dist/bin
../../config/nsinstall: cannot access
../../dist/SunOS5.6_sparc_OPT.OBJ/lib/ No such file or directory
make[1]: *** [install] Error 1
make[1]: Leaving directory
make: *** [install] Error 2

This looks like some sort of path problem because the library has built:

whars07h{gyles}24: cd SunOS5.6_OPT.OBJ/
whars07h{gyles}25: l
total 300
-rw-rw-r--   1 gyles    passport    15392 May  1 11:03 anchor.o
-rw-rw-r--   1 gyles    passport    77556 May  1 11:03 certdata.o
-rw-rw-r--   1 gyles    passport     1344 May  1 11:03 constants.o
-rw-rw-r--   1 gyles    passport     2180 May  1 11:03 find.o
-rw-rw-r--   1 gyles    passport     1892 May  1 11:03 instance.o
-rwxrwxr-x   1 gyles    passport   182440 May  1 11:03*
-rw-rw-r--   1 gyles    passport     1924 May  1 11:03 object.o
-rw-rw-r--   1 gyles    passport     1036 May  1 11:03 session.o
-rw-rw-r--   1 gyles    passport     1792 May  1 11:03 slot.o
-rw-rw-r--   1 gyles    passport     2276 May  1 11:03 token.o
whars07h{gyles}26: file  ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically linked,
not stripped

Comment 31

16 years ago
I've tried the CFLAGS= instead for CFLAGS+= patch in our solaris 7 builds with
Forte6 Update1 compilers and this solved the undefined symbols build problem.

Comment 32

16 years ago
Thank you for verifying my fix.  I checked it in on the trunk
and the NSS_3_2_BRANCH.
Last Resolved: 16 years ago
Priority: -- → P3
Resolution: --- → FIXED
Target Milestone: --- → 3.2.2

Comment 33

16 years ago
FYI. I can't get your putback yet since PSM 2.0 is still using NSS_CLIENT_TAG.
So for now I will have to continue to apply the patch until pull tags for PSM
2.0 are changed.

Comment 34

16 years ago
By the way, this is just a note of the behavior.  I've checked out Shirley's
build log.  We have set the CFLAGS and CXXFLAGS to -xO3 in the build
environment, but it appears that the nss build invoked by PSM is ignoring it. 
See example below:

cd nss; gmake libs
gmake[4]: Entering directory `/net/crumple.eng/export/nc-re/release/build/SUN-MO
cc -o SunOS5.7_OPT.OBJ/nssinit.o -c -O -KPIC -DSVR4 -DSYSV -D__svr4 -D__svr4__ -
/dt/include -I/usr/openwin/include -I/net/crumple.eng/export/nc-re/release/build
/SUN-MOZ/5.7/sparc-opt/mozilla/dist/include/nspr  -I../../../../dist/public/secu
rity -I../../../../dist/private/security -I../../../../dist/include -I../../../.
./dist/public/security -I../../../../dist/public/dbm  nssinit.c

It is using -O instead.  However, for now, it is sufficient enough for us to be
using -O for those files; so we don't worry much about that.  Just update it as
a note.

Comment 35

16 years ago
My fix (changing CFLAGS += to CFLAGS =) breaks the NSS build on
Windows NT.
Resolution: FIXED → ---

Comment 36

16 years ago
I backed out my fix.  I'm going to mark this bug

You can work around this problem by unsetting CFLAGS
in your environment.  If you need to specify a C
compiler flag for a configure script, do that on the
command line.  For example, with sh:
    CC=cc CFLAGS=-xO3 ./configure
Last Resolved: 16 years ago16 years ago
Resolution: --- → WONTFIX

Comment 37

16 years ago
The reason that the fix for this bug breaks our NT build
is that mozilla/security/nss/lib/fortcrypt/swfort/pkcs11/
defines -DSWFORT in CFLAGS:
With our fix, this macro define would be lost.  One way to avoid
this problem is to define -DSWFORT in DEFINES, which is more
appropriate anyway:
I checked in this change.  However, I still haven't checked in the
fix for this bug.
*** Bug 98578 has been marked as a duplicate of this bug. ***
*** Bug 100556 has been marked as a duplicate of this bug. ***

Comment 40

16 years ago
why can't we make this change inside an if !defined(XP_WIN) or something?

Comment 41

16 years ago
Now that the file that the fix broke has been
modified to avoid the problem, the fix may be checked in
again.  To be safe, I verified that no under
mozilla/security sets CFLAGS.

So I checked in the fix on the tip of NSS.  By checking in
this fix, we are requiring that clients of coreconf not set
CFLAGS in  This is not a serious limitation
because they can still achieve the same goal by setting the
components of CFLAGS, such as DEFINES and INCLUDES.
Resolution: WONTFIX → ---
Target Milestone: 3.2.2 → 3.4

Comment 42

16 years ago
This fix will go into NSS 3.4.

Note that the Mozilla client is using a stable
snapshot of the NSS 3.3 branch now, so it won't
pick up this fix until it upgrades to NSS 3.4
(mid-November the earliest).
Last Resolved: 16 years ago16 years ago
Component: Libraries → Build
Priority: P3 → P2
Resolution: --- → FIXED

Comment 43

16 years ago
*** Bug 107644 has been marked as a duplicate of this bug. ***

Comment 44

16 years ago
Today, the third duplicate of this bug was filed,
so I checked in the fix on the NSS_3_3_BRANCH
and will move the NSS_CLIENT_TAG.  The Mozilla
client will pick up this fix later today when
I move the NSS_CLIENT_TAG on security/coreconf/
Target Milestone: 3.4 → 3.3.2
You need to log in before you can comment on or make changes to this bug.