openldap

Robert Millan rmh@debian.org
Fri, 30 Jul 2004 19:17:05 +0200


I had to hack openldap badly to get it compile, here's a sample hunk:

--- openldap2-2.1.30.old/libraries/libldap/Makefile.in	2004-07-30 15:04:38.000000000 +0200
+++ openldap2-2.1.30/libraries/libldap/Makefile.in	2004-07-30 16:07:56.000000000 +0200
@@ -35,7 +35,7 @@
 LIB_DEFS = -DLDAP_LIBRARY
 
 XLIBS = $(LIBRARY) $(LDAP_LIBLBER_LA) $(LDAP_LIBLUTIL_A)
-XXLIBS = $(SECURITY_LIBS) $(LUTIL_LIBS)
+XXLIBS = $(SECURITY_LIBS) $(LUTIL_LIBS) $(LTHREAD_LIBS)
 NT_LINK_LIBS = $(LDAP_LIBLBER_LA) $(AC_LIBS) $(SECURITY_LIBS)
 UNIX_LINK_LIBS = $(LDAP_LIBLBER_LA) $(AC_LIBS) $(SECURITY_LIBS)

(where $(LTHREAD_LIBS) equals to "-lpthread")

libldap.so contains gnutls.o, and it seems gnutls.o brings dependencies on
pthread_mutex_something symbols. Therefore, I would expect that it's normal
that we had ot add "-lpthread". _However_:

 1) On GNU/Linux it also has gnutls.o with the pthread_* symbols, it doesn't
    pass -lpthread and works perfectly.

 2) Passing -lpthread when building the library did not sort _all_ of the
    problem. Looks like the utils in openldap that also link with libldap.so
    needed -lpthread too when linking with libldap.so (ld complains about
    unresolved symbols in libldap.so itself, not the utils).

 3) I've succesfuly linked libsasl2 with libldap2 without any hacks related
    to this problem. Note, though, that libsasl2 could be adding -lpthread
    on its own too..

I'm not sure what to do here. Adding -lpthread for libldap.so seems correct
but then why do we need -lpthread for the utils?

-- 
Robert Millan

(Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\
(kernel of *(Berkeley Software Distribution))