Last Comment Bug 200561 - Cannot load NSS programs due to failure on AIX platform
: Cannot load NSS programs due to failure on AIX platform
Product: NSPR
Classification: Components
Component: NSPR (show other bugs)
: 4.3
: Other AIX
: P1 critical (vote)
: 4.4
Assigned To: Wan-Teh Chang
: Wan-Teh Chang
Depends on:
  Show dependency treegraph
Reported: 2003-04-03 16:06 PST by Bishakha Banerjee
Modified: 2003-11-26 16:33 PST (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

NSS 3.8 QA output log of Backward Compatibility testing (14.71 KB, text/plain)
2003-04-03 16:07 PST, Bishakha Banerjee
no flags Details
Proposed workaround: do not include <string.h> in AIX optimized builds (862 bytes, patch)
2003-04-08 19:17 PDT, Wan-Teh Chang
no flags Details | Diff | Splinter Review

Description Bishakha Banerjee 2003-04-03 16:06:13 PST
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 Bishakha Banerjee 2003-04-03 16:07:57 PST
Created attachment 119365 [details]
NSS 3.8 QA output log of Backward Compatibility testing
Comment 2 Sonja Mirtitsch 2003-04-03 16:32:34 PST
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 Wan-Teh Chang 2003-04-03 17:32:51 PST
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 Wan-Teh Chang 2003-04-03 17:37:44 PST
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 Wan-Teh Chang 2003-04-03 17:41:07 PST
It should be

#if !(defined(AIX) && !defined(DEBUG))
#include <string.h>
Comment 6 Wan-Teh Chang 2003-04-08 19:17:19 PDT
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 Wan-Teh Chang 2003-04-08 19:23:12 PDT
I checked in the workaround on the NSPR TIP and

Note You need to log in before you can comment on or make changes to this bug.