Brett @Google wrote:
On Sat, Feb 14, 2009 at 7:40 AM, Howard Chu <hyc(a)symas.com
Looks like you ran out of memory to me.
No. It's memory corruption because his Solaris libldap is calling
into OpenLDAP's liblber. The only reliable solution is to remove
Solaris libldap from the machine and rebuild nss_ldap using
wouldn't LD_RUN=/my/openldap/lib or -R/my/openldap/lib options (for
shared libraries) or -L/my/openldap/lib (for static libraries) options
during compiling, normally be sufficient to force the shared library
link path at runtime (shared libraries) or link the openssl library
specifically at compile time (static libraries) to avoid the unrequested
solaris library surplus ?
If somebody has a split administrative model, it can be very hard to
twiddle with "stock" solaris, changing or removing the solaris LDAP may
not be possible..
The nss_ldap module still needs to be rebuilt. If you arrange for only the
OpenLDAP libraries to be present in the process, the nss_ldap module will
still crash if it was originally built against the Sun LDAP. They're
source-compatible, but they're not binary-compatible.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/