Thanks. Netscape Directory Server 7.0 will be released in a couple of months. The platforms will be RH AS 3, Solaris 9, Win2k, and HPUX 11.11. I'm not sure where you will be able to get the binaries - perhaps still http://enterprise.netscape.com. We're trying to work out the details in the wake of the acquistion of the software by Red Hat. We're also trying to figure out how to do binary LDAP C SDK releases. But you can always get the LDAP SDK binaries by extracting them from the NDS trial version package (the LDAP SDK is not timebombed).

Frank wrote:
I ran into this problem and saw a couple of posts on this here, so I decided to do a little HOWTO. Its short and very rough, but I think it'll help you out if you can't link new LDAP applications to current versions of glibc using old LDAP libraries.

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.
_______________________________________________
mozilla-directory mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-directory

Reply via email to