If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

shlibsign fails to load libfreebl3 on PA-RISC 1.1 HP-UX 11.11/11.00

RESOLVED FIXED in 3.13

Status

NSS
Build
P2
major
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: ul, Assigned: ul)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

7 years ago
During the build of SeaMonkey/Firefox or Thunderbird the build stops with error/core dump when the first NSS library is to be signed with shlibsign.

A standalone debug build of NSS_3_12_7_RTM / NSPR_4_8_6_RTM went through, but also failed to create the .chk files.

100% reproducable

HP-UX B.11.00 with last Qualitypack March 2004, C/ANSI-C 11.11.16 / aCC 3.70
S700 platform with PA-RISC 1.1 cpu.

From the OBJ/lib dir:
bash-3.2$ ../bin/shlibsign -v -i libsoftokn3.sl
/usr/lib/dld.sl: Can't open shared library: ../../../../dist/HP-UXB.11.00_DBG.OBJ/lib/libnspr4.sl
/usr/lib/dld.sl: No such file or directory
ABORT instruction (core dumped)

After manually setting SHLIB_PATH to the fully qualified OBJ/lib dir:
echo $SHLIB_PATH
/home/ulink/build/mozilla/dist/HP-UXB.11.00_DBG.OBJ/lib:/opt/gnome/lib:/usr/lib
bash-3.2$ ../bin/shlibsign -v -i libsoftokn3.sl
moduleSpec configdir='' certPrefix='' keyPrefix='' secmod='' flags=noCertDB, noM
odDB
C_Initialize failed: 0x00000030, CKR_DEVICE_ERROR
NSPR error code: -5977: Failure to load dynamic library
Initiailzing softoken failed: 0x00000030, CKR_DEVICE_ERROR
NSPR error code: -5977: Failure to load dynamic library

Seems the Makefile needs some -Wl,+s and/or -Wl,+b /PATH adjustment.
(Assignee)

Updated

7 years ago
Assignee: nobody → nobody
Component: Security → Build
Product: Core → NSS
QA Contact: toolkit → build
Version: unspecified → 3.12.7
(Assignee)

Comment 1

7 years ago
Here is the error out during my trial of a Firefox 1.5.0.12 build:

gmake[4]: Leaving directory `/home/ulink/src/mozilla/security/nss/cmd/shlibsign/mangle'
cd /home/ulink/src/mozilla/obj-hppa1.1-hp-hpux11.00/nss ; sh /home/ulink/src/mozilla/security/nss/cmd/shlibsign/./sign.sh /home/ulink/src/mozilla/obj-hppa1.1-hp-hpux11.00/dist \
        /home/ulink/src/mozilla/obj-hppa1.1-hp-hpux11.00/nss HP-UX \
        /home/ulink/src/mozilla/obj-hppa1.1-hp-hpux11.00/dist/lib /home/ulink/src/mozilla/obj-hppa1.1-hp-hpux11.00/dist/lib/libsoftokn3.sl
/home/ulink/src/mozilla/obj-hppa1.1-hp-hpux11.00/nss/shlibsign -v -i /home/ulink/src/mozilla/obj-hppa1.1-hp-hpux11.00/dist/lib/libsoftokn3.sl
NSS_Init failed: An I/O error occurred during security authorization.
gmake[3]: *** [/home/ulink/src/mozilla/obj-hppa1.1-hp-hpux11.00/dist/lib/libsoftokn3.chk] Error 1
gmake[3]: Leaving directory `/home/ulink/src/mozilla/security/nss/cmd/shlibsign'
gmake[2]: *** [libs] Error 2
gmake[2]: Leaving directory `/home/ulink/src/mozilla/obj-hppa1.1-hp-hpux11.00/security/manager'
gmake[1]: *** [tier_50] Error 2
gmake[1]: Leaving directory `/home/ulink/src/mozilla/obj-hppa1.1-hp-hpux11.00'
gmake: *** [default] Error 2
Please suggest an appropriate -Wl adjustment.
The NSS team no longer has the HP boxes on which to work on this.
Summary: shlibsign fails on 32bit HP-UX 11.00 → During FF build, shlibsign fails to find libnspr4.sl on 32bit HP-UX 11.00
(Assignee)

Comment 3

7 years ago
Even on HP-UX B.11.11 on a PA-RISC 2.0 machine exactly same error:

cd /home/ulink/src/mozilla/obj-hppa2.0n-hp-hpux11.11/nss ; sh /home/ulink/src/mozilla/security/nss/cmd/shlibsign/./sign.sh /home/ulink/src/mozilla/obj-hppa2.0n-hp-hpux11.11/dist \
        /home/ulink/src/mozilla/obj-hppa2.0n-hp-hpux11.11/nss HP-UX \
        /home/ulink/src/mozilla/obj-hppa2.0n-hp-hpux11.11/dist/lib /home/ulink/src/mozilla/obj-hppa2.0n-hp-hpux11.11/dist/lib/libsoftokn3.sl
/home/ulink/src/mozilla/obj-hppa2.0n-hp-hpux11.11/nss/shlibsign -v -i /home/ulink/src/mozilla/obj-hppa2.0n-hp-hpux11.11/dist/lib/libsoftokn3.sl
/home/ulink/src/mozilla/security/nss/cmd/shlibsign/./sign.sh[56]: 18186 Memory fault(coredump)
gmake[3]: *** [/home/ulink/src/mozilla/obj-hppa2.0n-hp-hpux11.11/dist/lib/libsoftokn3.chk] Error 139

I have diffed the Source snapshot provided by HP for their FF 2.0.0.19 build and found nothing below mozilla/security... But their FF 20019 shows it was built on  a hppa2.0w host, meaning 64bit O/S install, no esoteric .mozconfig flags.
(Assignee)

Updated

7 years ago
Summary: During FF build, shlibsign fails to find libnspr4.sl on 32bit HP-UX 11.00 → During FF build, shlibsign fails to find libnspr4.sl on 32bit HP-UX 11.11/11.00
(Assignee)

Updated

7 years ago
Depends on: 587426
(Assignee)

Comment 4

7 years ago
When trying to build the HP provided source tarball for FF 2.0.0.19 the error looks more specific:
/home/ulink/ffbuild/mozilla/obj-hppa1.1-hp-hpux11.00/nss/shlibsign -v -i /home/ulink/ffbuild/mozilla/obj-hppa1.1-hp-hpux11.00/dist/lib/libsoftokn3.sl
/usr/lib/dld.sl: Unresolved symbol: _pr_find_getipnodebyname (code)  from /home/ulink/ffbuild/mozilla/obj-hppa1.1-hp-hpux11.00/dist/lib/libnspr4.sl
/home/ulink/ffbuild/mozilla/security/nss/cmd/shlibsign/./sign.sh[56]: 7744 Abort(coredump)

Which directs me into NSPR IPv6 code.
(Assignee)

Comment 5

7 years ago
Resetting to UNCONFIRMED as I suspect the bug in NSPR  bug# 587426
Severity: normal → minor
Status: NEW → UNCONFIRMED
Ever confirmed: false
(Assignee)

Comment 6

7 years ago
After sorting out NSPR IPv6 issue I can confirm this bug in NSS for PA-RISC1.1 only. Building on a PA-RISC2.0 works.

HP-UX B.11.11 with IPv6 addon (exact product name changed over the years) on PA2.0 minimum.

HP-UX B.11.00 was EoL about 4 or 5 years ago, PA-RISC 1.1 workstation are not supported by HP even longer... Just a try on my lovely old HP9000 B160L workstation.

If there is any interest in fixing PA-RISC 1.1 I will help/try/compile and test.
Else I'm happy with setting WORKSFORME.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 7

7 years ago
Tracked down the bug:

the runtime detection of CPU type in 
mozilla/security/nss/lib/freebl/loader.c around line# 115
doesn't do what it should do for PA-RISC 1.1, so the libfreebl_int32_3.sl won't ever get loaded.
On PA-RISC 2.0 the libfreebl_fpu32_3.sl is loaded and working.

Changed the Makefiles for only building a single libfreebl3.sl with the defines for the libfreebl_int32_3.sl case and removed the runtime detection -> and got a working SeaMonkey 1.1.17 with SSL support (used for posting this bugzilla comment)

If no one cared for PA-RISC1.1 for quite a few years building a single freebl3 lib for PA-RISC2.0 (leaving the alternate PA1.1 flags/defines within a comment) should be the straightforward cleanup solution.

The last known working runtime detection was in loader.c of MOZILLA_1_7_13_RELEASE tag. So loader.c can be fixed, too.

Plz comment for the preferred direction, and I will provided the patch and testing on HP-UX.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---
(Assignee)

Updated

7 years ago
Summary: During FF build, shlibsign fails to find libnspr4.sl on 32bit HP-UX 11.11/11.00 → shlibsign fails to load libfreebl3 on PA-RISC 1.1 HP-UX 11.11/11.00
(Assignee)

Comment 8

7 years ago
Created attachment 476627 [details] [diff] [review]
dirty hack for verification
Assignee: nobody → ul.mcamafia
uh, no.

The run time detection does exactly what it should for PA Risc 1.1 and 2.0.
The detection is unchanged since it was first written (rev 1.1 of the file).
I believe your problem is due to not having the correct .sl files in the 
right place.  

You wrote that "the last known working runtime detection was in loader.c 
of MOZILLA_1_7_13_RELEASE tag."  That corresponds to revision 1.16 of loader.c.
The detection has not changed at any time. However, some things have changed
since then, and they are the names of the dynamically loaded .sl files.  
In rev 1.16, the names of the files were: 
         "libfreebl_hybrid_3.sl"    : "libfreebl_pure32_3.sl"
and in rev 1.22, those were changed to 
         "libfreebl_32fpu_3.sl"     : "libfreebl_32int32_3.sl" ; 

These changes were made 5 years ago and have worked 100% ever since.
If you have the right .sl files in the right places, it will work.
(Assignee)

Comment 10

7 years ago
(In reply to comment #9)

> The run time detection does exactly what it should for PA Risc 1.1 and 2.0.
> The detection is unchanged since it was first written (rev 1.1 of the file).
> I believe your problem is due to not having the correct .sl files in the 
> right place.  

When I build without the hack, both 
 libfreebl_32fpu_3.sl
and
 libfreebl_32int_3.sl 
 (but not libfreebl_32int32_3.sl!)
are build.

So the detection will work but loader.c does NOT what expected to do on PA-RISC 1.1 within this function. Simple typo.

> These changes were made 5 years ago and have worked 100% ever since.
> If you have the right .sl files in the right places, it will work.

I guess the PA-RISC 1.1 path is broken for 5 years and this code path wasn't tested because there wasn't a machine. 
Given the market share of HP-UX and that developers prefer faster workstations it's not unnreasonable that no one ever hit this bug before.
Everything released on the HP website after Mozilla 1.7.13 simply required a PA-RISC 2.0.
It was hard to believe for me too :-)

But that's why I consider the cleanup and simplification using the PA-RISC 2.0 flags/assembly units instead of the simple fix in loader.c
It's proved by 5 years no one needed the PA-RISC 1.1 code path any more.
It did the simplification for narrowing down the error. Hard to debug when you don't know where to start. I never hit loader.c in my debugging session.
(Assignee)

Comment 11

7 years ago
Created attachment 476774 [details] [diff] [review]
fix libname typo in loader.c

Fixed libname typo for PA-RISC1.1 case

And voila, shlibsign works when NSS_Init finds it's freebl lib.
Attachment #476627 - Attachment is obsolete: true
Attachment #476774 - Flags: review?
(Assignee)

Updated

7 years ago
Attachment #476774 - Flags: review? → review?(nelson)
Severity: minor → major
Target Milestone: --- → 3.13
Comment on attachment 476774 [details] [diff] [review]
fix libname typo in loader.c

r=nelson for 3.13
Attachment #476774 - Flags: review?(nelson) → review+
Bug 586790: shlibsign fails to load libfreebl3 on PA-RISC 1.1 HP-UX 11.11/11.00
Patch contributed by Uli Link (:ul-mcamafia) <ul.mcamafia@linkitup.de>
r=nelson

Checking in freebl/loader.c; new revision: 1.53; previous revision: 1.52
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Priority: -- → P2
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.