Get PSM 2.0 working on HPUX

VERIFIED FIXED in mozilla0.9.1

Status

()

VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: shannond, Assigned: shannond)

Tracking

Trunk
mozilla0.9.1
HP
HP-UX
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Assignee)

Description

18 years ago
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
(Assignee)

Updated

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

Updated

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........
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 2

18 years ago
Oops!  You are correct, thanks for catching that!
Status: NEW → ASSIGNED

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("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)

Updated

18 years ago
Blocks: 18687
(Assignee)

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.
(Assignee)

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.

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

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/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 9

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

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
r=wtc.

Comment 12

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

Comment 13

18 years ago
Verified using daily trunk mozilla build #2001050909.
Status: RESOLVED → VERIFIED

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.