Get PSM 2.0 working on HPUX

VERIFIED FIXED in mozilla0.9.1



18 years ago
18 years ago


(Reporter: shannond, Assigned: shannond)



Firefox Tracking Flags

(Not tracked)



(3 attachments)



18 years ago
BuildID:    2001041710

PSM 2.0 is now available in the Mozilla tree.  Using the following build steps:

1) cvs co mozilla/
2) cd mozilla
3) gmake -f checkout
4) gmake -f checkout BUILD_MODULES=psm2
5) configure
6) gmake
7) configure --enable-modules=psm2
8) gmake BUILD_MODULES=psm2

PSM will build and run on Linux.  In order to get the build to complete on HPUX
you must link a couple of directories in  mozilla/dist to compensate for a
naming inconsistency (in mozilla/dist):  ln -s HP-UXB.11.00_DBG.OBJ

After this the build completes but PSM function correctly.

Reproducible: Always
Steps to Reproduce:
1. Complete build steps 1-8 in steps above.
2. On step 8 a build error will occur, from the mozilla/dist directory, do this:
  ln -s HP-UXB.11.00_DBG.OBJ HP-UXB.11.00_hppa_DBG.OBJ

3.  restart step 8
The build will complete successfully.  Run the browser.

Actual Results:  no (or non-functioning) PSM:
 - trying to connect to gives a dialog box saying:
"https is not a registered protocol"
 - Personal Security Manager cannot be invoked	

Expected Results:  The browser should be able to connect to secure sites


18 years ago
Blocks: 18687
QA Contact: ckritzer → barrettl


18 years ago
No longer blocks: 18687

Comment 1

18 years ago
"After this the build completes but PSM function correctly."  I think you meant 
to say that PSM functions INcorrectly, right?  Confirming this bug and setting 
to NEW........
Ever confirmed: true

Comment 2

18 years ago
Oops!  You are correct, thanks for catching that!

Comment 3

18 years ago
Well after a bunch of debugging, I tracked down the problem (don't have 
the perfect fix, yet... but am working).  

Anyhow in mozilla/security/nss/lib/freebl/loader.c for HP, we
are attempting to do a shl_load(""); (somewhere
around line 193).  Well is 'installed' in
mozilla/dist/lib, which is not (by default) a part of SHLIB_PATH
so when we run mozilla, and calls libfreebl.a's loader
and that tries to load, shl_load fails because is NOT in mozilla/dist/bin.

If you set SHLIB_PATH to mozilla/dist/lib and run mozilla...
shl_load finds and PSM2.0 works.

So my question to the powers that be... where should
(or equivalent be installed into, so that it gets picked up...?)
I am assuming it should be in mozilla/dist/bin



18 years ago
Blocks: 18687

Comment 4

18 years ago
Since Sun is having some of the same problems that we are, additional
conversation is going on in bug 77123 - Get PSM2.0 build on Solaris.  From this
bug I tried wtc's first patch to fix the object dir name differences and
Margaret's patch to fix where the required libs are installed.  Both fixes
worked.  I'm attaching this combined patch which contains the combination of the
two above patches plus an extra fix Jim told me about for HPUX.

Comment 5

18 years ago
Created attachment 33252 [details] [diff] [review]
patch that fixes psm2 on HPUX

Comment 6

18 years ago
Created attachment 33523 [details] [diff] [review]
updated patch for both HP & Solaris

Comment 7

18 years ago
I have updated the patch to incorporate WTC's, Margaret's and
Shannon's diffs.  I have tested it on HP & Linux.

-the +='s in the sub Makefile.ins is a requirement on COMPONENT
 shared libraries.  If you lookin mozilla/config/ you
 will see that there is special code based on IS_COMPONENT=1
 and it sets EXTRA_DSO_LDOPTS, so you have to += this variable
 if you have already includes

I am looking for review and approval so that I can check this in.
wtc?  cls?
-HP requires ifneq to be all the way left in a Makefile

Comment 8

18 years ago
A few obersvations on patch 33523:
1) When assigning variables from the coreconf space, use the := assignment
operator to force expansion at the time of assignment.  This prevents values
from config variables from over-writing the desired coreconf values.  In the
section where you define CPU_TAG (copied from coreconf/, use the :=
operator to avoid the problem.

2) I think it'd be better to have 2 variables for the new shared libraries
you're trying to install (freebl_pure332_3 and freebl_hybrid_3) like the
LOADABLE_ROOT_MODULE variable.  That's because the library was created using the
coreconf variable name space, so you should create its full name using the
coreconf variable name space for consistency.

Fix the above 2 concerns and r=javi

Comment 9

18 years ago
Created attachment 33541 [details] [diff] [review]
updated mozilla/security/manager/

Comment 10

18 years ago
r=javi on latest patch.  (I believe the mozilla/security/manager partition has
been opened up, so you should be able to check it in.)

Comment 11

18 years ago

Comment 12

18 years ago
Fix checked in.
Last Resolved: 18 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla0.9.1

Comment 13

18 years ago
Verified using daily trunk mozilla build #2001050909.

Comment 14

18 years ago
*** Bug 77123 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.