Closed Bug 76370 Opened 24 years ago Closed 24 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: 24 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: