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: nobody → nobody
Component: Security → Build
Product: Core → NSS
QA Contact: toolkit → build
Version: unspecified → 3.12.7
Here is the error out during my trial of a Firefox 22.214.171.124 build: gmake: 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: *** [/home/ulink/src/mozilla/obj-hppa1.1-hp-hpux11.00/dist/lib/libsoftokn3.chk] Error 1 gmake: Leaving directory `/home/ulink/src/mozilla/security/nss/cmd/shlibsign' gmake: *** [libs] Error 2 gmake: Leaving directory `/home/ulink/src/mozilla/obj-hppa1.1-hp-hpux11.00/security/manager' gmake: *** [tier_50] Error 2 gmake: 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
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: 18186 Memory fault(coredump) gmake: *** [/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 126.96.36.199 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.
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
When trying to build the HP provided source tarball for FF 188.8.131.52 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: 7744 Abort(coredump) Which directs me into NSPR IPv6 code.
Resetting to UNCONFIRMED as I suspect the bug in NSPR bug# 587426
Severity: normal → minor
Status: NEW → UNCONFIRMED
Ever confirmed: false
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: 9 years ago
Resolution: --- → WORKSFORME
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 → ---
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
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.
(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.
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 #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) <firstname.lastname@example.org> r=nelson Checking in freebl/loader.c; new revision: 1.53; previous revision: 1.52
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago → 8 years ago
Priority: -- → P2
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.