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

Status: RESOLVED FIXED

(NSS :: Build, defect, P2)

Description

[Uli Link (:ul-mcamafia)]

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.

Comment 1

[Uli Link (:ul-mcamafia)]

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

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Please suggest an appropriate -Wl adjustment.
The NSS team no longer has the HP boxes on which to work on this.

Comment 3

[Uli Link (:ul-mcamafia)]

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.

Comment 4

[Uli Link (:ul-mcamafia)]

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.

Comment 5

[Uli Link (:ul-mcamafia)]

Resetting to UNCONFIRMED as I suspect the bug in NSPR  bug# 587426

Comment 6

[Uli Link (:ul-mcamafia)]

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.

Comment 7

[Uli Link (:ul-mcamafia)]

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.

Comment 8

[Uli Link (:ul-mcamafia)]

Attachment: dirty hack for verification

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 10

[Uli Link (:ul-mcamafia)]

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

Comment 11

[Uli Link (:ul-mcamafia)]

Attachment: 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.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 476774 [details] [diff] [review]
fix libname typo in loader.c

r=nelson for 3.13

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

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) <[e-mail]>
r=nelson

Checking in freebl/loader.c; new revision: 1.53; previous revision: 1.52