While testing the binaries from the autotools based build on HP-UX, I was unable to get ns-slapd to run due to an unresolved symbol. I was seeing the following errors in the errors log: error:[20/Feb/2007:10:31:55 -0800] - Netscape Portable Runtime error -5977: Unsatisfied data symbol '_ZTVN10__cxxabiv120__si_class_type_infoE' in load module '//opt/fedora-ds/lib/libicui18n.so.34'. On HP-UX, the program that contains the main() function must be linked with the C++ compiler (aCC -AA in our case) if it loads any C++ shared libraries. The fix is to tell libtool to use the C++ compiler to link ns-slapd.
Created attachment 148457 [details] Proposed Fix
Checked into ldapserver (HEAD). Thanks to Rich for the review! Checking in Makefile.am; /cvs/dirsec/ldapserver/Makefile.am,v <-- Makefile.am new revision: 1.28; previous revision: 1.27 done Checking in Makefile.in; /cvs/dirsec/ldapserver/Makefile.in,v <-- Makefile.in new revision: 1.32; previous revision: 1.31 done Checking in ltmain.sh; /cvs/dirsec/ldapserver/ltmain.sh,v <-- ltmain.sh new revision: 1.11; previous revision: 1.10 done
Created attachment 148612 [details] Additional fix AN additional change is needed to allow ns-slapd to be linked on non HP-UX systems. It turns out that you need to explicitly set ns_slapd_LINK for all cases . By even attempting to override the implicit setting one only one platform, ns_slapd_LINK will not be implicitly defined at all.
Checked additional fix from comment #3 into ldapserver (HEAD). The fix was actually written by Rich, and reviewed and tested by myself and Noriko. Checking in Makefile.am; /cvs/dirsec/ldapserver/Makefile.am,v <-- Makefile.am new revision: 1.29; previous revision: 1.28 done Checking in Makefile.in; /cvs/dirsec/ldapserver/Makefile.in,v <-- Makefile.in new revision: 1.33; previous revision: 1.32 done