Closed
Bug 76370
Opened 24 years ago
Closed 24 years ago
Get PSM 2.0 working on HPUX
Categories
(Core :: Security, defect)
Tracking
()
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: shannond, Assigned: shannond)
References
Details
Attachments
(3 files)
2.00 KB,
patch
|
Details | Diff | Splinter Review | |
2.91 KB,
patch
|
Details | Diff | Splinter Review | |
1.69 KB,
patch
|
Details | Diff | Splinter Review |
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
Comment 1•24 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........
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 2•24 years ago
|
||
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
Assignee | ||
Comment 4•24 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.
Assignee | ||
Comment 5•24 years ago
|
||
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
Comment 8•24 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/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
Comment 10•24 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•24 years ago
|
||
r=wtc.
Comment 12•24 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla0.9.1
Comment 13•24 years ago
|
||
Verified using daily trunk mozilla build #2001050909.
Status: RESOLVED → VERIFIED
Comment 14•24 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.
Description
•