The default bug view has changed. See this FAQ.

Cannot load NSS programs due to failure on AIX platform



14 years ago
14 years ago


(Reporter: Bishakha Banerjee, Assigned: Wan-Teh Chang)


Firefox Tracking Flags

(Not tracked)



(2 attachments)



14 years ago
While running Backward Compatibility NSS 3.8 tests (against BC binaries of NSS
3.7) on AIX, failures to load NSS cmds were seen for the OPT build.

Log files report a failure and are attached.

Comment 1

14 years ago
Created attachment 119365 [details]
NSS 3.8 QA output log of Backward Compatibility testing

Comment 2

14 years ago
exactly the same failure is seen at Sun
AIX 43, 32 and 64 bit optimized builds only. 3/30 was the last time that we ran
backward compatibility tests on AIX 4.3, then they passed init: Testing PATH
against LIB
which: 0652-141 There is no certutil in . /u/svbld/bin /tools/ns/bin /bin
/usr/bin /usr/sbin /usr/ccs/bin /usr/dist/local/exe /usr/bin/X11 /usr/audio/bin
/tools/contrib/bin /usr/local/bin. Certutil Tests =============================== Creating a CA Certificate ========================== Creating CA Cert DB --------------------------
certutil -N -d . -f ../
exec(): 0509-036 Cannot load program certutil because of the following errors:
	0509-130 Symbol resolution failed for certutil because:
	0509-136   Symbol memcpy (number 45) is not exported from
		   dependent module
	0509-192 Examine .loader section symbols with the
		 'dump -Tv' command. Exit: 5 Fatal - failed to create CA SSL tests ===============================


Comment 3

14 years ago
This problem was introduced by the fix for bug 192962.

In NSPR 4.3 Beta 1 or earlier, exports memcpy
because it calls memcpy but does not include <string.h>.

The mere linking with causes an executable
to resolve four libc symbols with

spd12:/u/wtc/nspr-4.3b1/aix.opt/pr/tests 186% cat foo.c
int main() { return 0; }
spd12:/u/wtc/nspr-4.3b1/aix.opt/pr/tests 187% xlC_r -o foo foo.c -brtl -L../../d
ist/lib -lnspr4
spd12:/u/wtc/nspr-4.3b1/aix.opt/pr/tests 196% dump -Tv foo | grep
[11]    0x00000000    undef      IMP     DS EXTref memcpy
[12]    0x00000000    undef      IMP     DS EXTref strcmp
[13]    0x00000000    undef      IMP     DS EXTref memmove
[14]    0x00000000    undef      IMP     DS EXTref bcopy

So, there is nothing an app can do to prevent this.  As shown
above, foo.c does not call any functions.

Between NSPR 4.3 Beta 1 and RTM, I added the necessary #include
<string.h> to NSPR.  This caused in NSPR 4.3 RTM to
not export memcpy.  Therefore, executables that were linked with
NSPR 4.3 Beta 1 or earlier get an unresolved memcpy reference
with the in NSPR 4.3 RTM.

I can easily restore the accidental memcpy export by ifdef'ing
one of the #include <string.h> like this:

#ifndef AIX
#include <string.h>

But I need a better solution so that we don't remove the memcpy
export again in the future.

Comment 4

14 years ago
Note that the workaround should be

#if !defined(AIX) && !defined(DEBUG)
#include <string.h>

because we were including <string.h> in debug builds.

Comment 5

14 years ago
It should be

#if !(defined(AIX) && !defined(DEBUG))
#include <string.h>

Comment 6

14 years ago
Created attachment 119910 [details] [diff] [review]
Proposed workaround: do not include <string.h> in AIX optimized builds

I am not happy with this workaround, but I don't have time
to investigate this problem and come up with the right

Comment 7

14 years ago
I checked in the workaround on the NSPR TIP and
Severity: normal → critical
Last Resolved: 14 years ago
Priority: -- → P1
Resolution: --- → FIXED
Whiteboard: [4.3.1]


14 years ago
Whiteboard: [4.3.1]
Target Milestone: --- → 4.4
You need to log in before you can comment on or make changes to this bug.