As surmised @c4f4t0r, you're not (yet) having configuration problems -- you're having build related problems.
TL;DR: don't use dynamic backends, they're mostly broken unless you fiddle with the build process. Skip to the update below for the gruesome details...
You probably have old or non-OpenLDAP LDAP libraries in the default system locations. I do not believe the
configure script is smart enough to test for this condition, or that the build process is sufficiently robust to handle it. For example if an old
libldap.so is found in a system library location then it will be used in preference to the correct and freshly installed
libldap.so at runtime. Running
back_ldap-2.4.so should show this.
You may be able to fix this (without rebuilding) by adding the relevant directory to the environment variable
LD_LIBRARY_PATH so that the directory with the newest OpenLDAP libraries is searched first (make sure to
export the variable).
Or, fix it (preferably) at build time, by running
configure with the
LDFLAGS environment variable set with an
RPATH which will hard-code a library search path into the binaries you build.
You haven't given your
configure options or installation path etc. I have used variations on this in the past:
export LDFLAGS="-L/usr/local/ssl/lib -Wl,-rpath,/usr/local/ssl/lib"
in the case where I want to use a non-system OpenSSL, the same applies for using a non-system version of BerkeleyDB. On Solaris you may need to use "-R" instead of "-rpath" (if you're using
gcc with the Sun linker rather than the GNU linker):
export LDFLAGS="-L/usr/local/ssl/lib -R/usr/local/ssl/lib"
In your case you probably just need to set the rpath (
-L (though I recommend using both when for the cases of OpenSSL and BerkeleyDB).
Update You are building with:
/configure --prefix=/usr --sysconfdir=/etc --enable-slapd --enable-crypt \
--enable-modules --enable-bdb=mod --enable-hdb=mod --enable-ldap=yes \
--enable-perl=mod --enable-overlays=mod --with-tls --with-gnu-ld
--enable-ldap=yes", this builds the LDAP-backend statically into
slapd, it does not create a dynamically loadable
--enable-ldap=mod). One possibility is that you have a stray
back_ldap.so that you are trying to load into your server, and an un-needed
moduleload back_ldap. However,
slapd will not allow you to load a dynamic module when a static module of the same name exists, so your
slapd binary does not appear to be as you have described.
slapd -VVV to confirm static backends.
back_ldap is static you should be able to work around this problem, and remove any errant
moduleload and stale
.so for good measure.
I have a strong suspicion there is some libtool, dependency error or linker issue lurking here. I can reproduce this with a dynamic back_ldap.
ldap_add_ext is indeed an unresolved symbol which isn't necessarily a problem (due to explicit
dlopen() for modules), but that symbol is not exported by
slapd. It is exported by
libldap.so, but that's not a dependency of
back_ldap.so and nothing else causes
libldap to be loaded. (This also means the advice I gave above won't solve the problem, since it's not simply as simple as a library path problem.)
What's happening (i.e. the error you're seeing) is that the symbol
ldap_add_ext isn't being resolved until it's required ("lazy" binding). When you try to add an LDAP object it is finally required of course. Then the wheels come off. (Should you feel the urge, you can break it at start-time by exporting
LD_BIND_NOW=1 which turns off lazy binding, then start
slapd, though odds are a different symbol will trip it.)
Right now the simplest option is to work with a static
--enable-ldap=yes, and perhaps
make clean && make depend && make install to be certain that
slapd is correctly built). A less simple option is to use
LD_PRELOAD=/usr/lib/libldap_r.so to work around the dependency problem, and cross-your fingers hoping that doesn't have some odd side-effects.
OK, this ancient email covers the problem: http://www.openldap.org/lists/openldap-software/200211/msg00469.html
slapd is linked against a static
libldap_r.a by default, this limits the symbols that will be available to those known at link time. Since the dynamic modules are loaded at run time with
dlopen() the linker doesn't have visibility of their requirements (symbols/libraries).
One might reasonably conclude that dynamic building of (some) backends has been pretty much broken for some time.
So, either don't use dynamic backends (recommended), or fudge the build (not so recommended) with something like:
make depend && make
LTSTATIC="" make -e # alternative to editing the Makefile
slapd against the
libldap_r.so you just built instead of the
.a, so all symbols can be loaded when needed (it also makes
slapd about 15% smaller on disk). I haven't run an operational LDAP server with this, YMMV. There must be some similar or alternative solutions used by distros...