Closed Bug 76370 Opened 23 years ago Closed 23 years ago

Get PSM 2.0 working on HPUX

Categories

(Core :: Security, defect)

HP
HP-UX
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: shannond, Assigned: shannond)

References

Details

Attachments

(3 files)

BuildID:    2001041710

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

1) cvs co mozilla/client.mk
2) cd mozilla
3) gmake -f client.mk checkout
4) gmake -f client.mk 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
HP-UXB.11.00_hppa_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 https://www.verisign.com 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
Blocks: 18687
QA Contact: ckritzer → barrettl
No longer blocks: 18687
"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........
Status: UNCONFIRMED → NEW
Ever confirmed: true
Oops!  You are correct, thanks for catching that!
Status: NEW → ASSIGNED
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("libfreebl_hybrid_3.sl"); (somewhere
around line 193).  Well libfreebl_hybrid_3.sl is 'installed' in
mozilla/dist/lib, which is not (by default) a part of SHLIB_PATH
so when we run mozilla, and libpipnss.sl calls libfreebl.a's loader
and that tries to load libfreebl_hybrid_3.sl, shl_load fails because
libfreebl_hybrid_3.sl is NOT in mozilla/dist/bin.

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

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

Blocks: 18687
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.
I have updated the patch to incorporate WTC's, Margaret's and
Shannon's diffs.  I have tested it on HP & Linux.

NOTES:
-the +='s in the sub Makefile.ins is a requirement on COMPONENT
 shared libraries.  If you lookin mozilla/config/rules.mk 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 rules.mk

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
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/ruleset.mk), 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
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.)
r=wtc.
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla0.9.1
Verified using daily trunk mozilla build #2001050909.
Status: RESOLVED → VERIFIED
*** 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.

Attachment

General

Creator:
Created:
Updated:
Size: