F.
+-------------------------------------------------------------------------+ | ISSUES WITH MOZILLA / SUN / IPLANET / NETSCAPE's | | LDAP C SDK AND NEWER VERSIONS OF GLIBC ON LINUX | | | | FRH, 2004.10.29 | +-------------------------------------------------------------------------+
This is a ROUGH summary of things I found out regarding errors I was getting when
trying to compile and link LDAP applications with current versions of glibc on Linux
machines.
PROBLEM
The old binary releases were linked against older versions of glibc that is no longer
compatible the the glibc versions be shipped with more current flavors of Linux. For
example, the older binaries work on a RHL 7.3 box with the following glibc:
/lib/libc.so.6 -> libc-2.2.5.so
a newer RHEL 3.2 box install gives me:
/lib/libc.so.6 -> libc-2.3.2.so
The problem manifests itself when you try and build a new LDAP application against the
older binaries from the tarball binary distribution. You'll get an undefined reference
to __ctype_b error. __ctype_b is now a hidden symbol for newer glibc libraries.
Apparently the parenthesis indicate the new hidden status. You can see the difference
using objdump:
OLD RHL 7.3:
objdump --dynamic-syms /lib/libc.so.6 | grep '__ctype_b$'
0012ec20 g DO .data 00000004 GLIBC_2.0 __ctype_b
NEW RHEL 3.2:
objdump --dynamic-syms /lib/libc.so.6 | grep '__ctype_b$'
001369d8 g DO .data 00000004 (GLIBC_2.0) __ctype_b
SOLUTION
The solution is to rebuild the libraries from source, linking them against the newer
version(s) of glibc. I just don't know why (Java) Sun has not released more current
binary versions (Java) of the LDAP C SDK (Java). Perhaps it has something to do with
their renamed LDAP application suite that all start with the prefix "Sun Java System".
Hmm.
Let get back on topic. Follow the instructions at:
http://www.mozilla.org/directory/csdk.html
regarding the dependancies NSS, NSPR, & DBM first. I built those from CVS source. Then
download the LDAP C SDK CVS source and follow the compilation instructions at the
above site. When compiling the libraries, you'll get a bunch of output in the dist
directory and subdirectories. I did NOT get fresh versions of ldapsearch etc. I DID
get fresh versions of libldap50.so etc. You may have to perform searches for the files
you want from the dist/ directory and move them in piecemeal fashion. If you use cp,
make sure to use the -L option to force the dereferencing of links.
find . -name libldap50.so
find . -name libssldap50.so
find . -name ldap.h
find . -name libnss3.so
etc.
You need to be able to reference these files when you compile new applications. There
are a couple of ways to do this. One of the simpler is to just copy them into the
respective directories under:
/usr/local/
and make sure that:
/usr/local/bin/
is in your $PATH and the you reference:
/usr/local/lib/
as a relevant library directory when you build (compile & link) new programs. That
worked for me. I didn't run the test script yet, but I've performed searches in both
cleartext and SSL from freshly compiled and linked programs so I think its OK. But I
should still really run the acceptance test when I get a chance:
http://www.mozilla.org/directory/csdk-tests.html
Perhaps someone at either Sun or Mozilla.org could create some newer binary
distributions for all of us soon? I hope this helps some in the meantime.
F.
