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))