Как и предполагалось @ c4f4t0r, у вас (пока) нет проблем с конфигурацией - у вас проблемы со сборкой .
TL; DR: не используйте динамические бэкэнды, они в основном не работают, если вы не возитесь с процессом сборки. Пропустите к обновлению ниже для ужасных деталей ...
Вероятно, у вас есть старые или не-OpenLDAP библиотеки LDAP в системных расположениях по умолчанию. Я не верю, что configureсценарий достаточно умен, чтобы проверить это условие или что процесс сборки достаточно устойчив, чтобы справиться с ним. Например, если старый файл libldap.soнаходится в системной библиотеке, он будет использоваться вместо правильного и только что установленного libldap.soво время выполнения. Бег lddпротив back_ldap-2.4.soдолжен показать это.
Вы можете исправить это (без перестройки), добавив соответствующий каталог в переменную среды, LD_LIBRARY_PATHчтобы сначала искать каталог с новейшими библиотеками OpenLDAP (убедитесь, что exportпеременная).
Или это исправить (предпочтительно) во время сборки, запустив configureс LDFLAGSпеременным окружением , установленный с RPATHкоторой будет жестко закодировать библиотеку пути поиска в бинарные файлы вы строите.
Вы не указали свои configureпараметры, путь установки и т. Д. Я использовал варианты этого в прошлом:
export LDFLAGS="-L/usr/local/ssl/lib -Wl,-rpath,/usr/local/ssl/lib"
в случае, когда я хочу использовать несистемный OpenSSL, то же самое относится и к несистемной версии BerkeleyDB. В Solaris вам может понадобиться использовать «-R» вместо «-rpath» (если вы используете gccкомпоновщик Sun, а не компоновщик GNU):
export LDFLAGS="-L/usr/local/ssl/lib -R/usr/local/ssl/lib"
В вашем случае вам, вероятно, просто нужно установить rpath ( -Wl,-rpathили -R), а не -L(хотя я рекомендую использовать оба варианта для случаев OpenSSL и BerkeleyDB).
Обновление Вы строите с:
/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», это статически встраивает бэкэнд LDAPslapd , не создает динамически загружаемый back_ldap.so(то есть --enable-ldap=mod). Одна из возможностей заключается в том, что у вас есть заблуждение, back_ldap.so которое вы пытаетесь загрузить на свой сервер, и ненужное moduleload back_ldap. Однако slapdвы не сможете загружать динамический модуль, когда существует статический модуль с тем же именем, поэтому ваш slapdдвоичный файл выглядит не так, как вы описали.
Запустите slapd -VVVдля подтверждения статических бэкэндов.
Предполагая, что back_ldapон статичен, вы должны быть в состоянии обойти эту проблему и удалить все заблуждения moduleloadи устаревшие .soдля хорошей меры.
У меня есть сильное подозрение, что здесь есть некоторые проблемы с libtool, зависимостью или компоновщиком. Я могу воспроизвести это с динамическим back_ldap. ldap_add_extэто действительно неразрешенный символ, который не обязательно является проблемой (из-за явного dlopen()для модулей), но этот символ не экспортируется slapd. Он будет экспортироваться libldap.so, но это не зависимость , back_ldap.soа больше ничего не вызывает , libldapчтобы быть загружен. (Это также означает, что совет, который я дал выше, не решит проблему, поскольку она не так проста, как проблема с путями в библиотеке.)
То, что происходит (то есть ошибка, которую вы видите), заключается в том, что символ ldap_add_extне разрешается до тех пор, пока он не потребуется («ленивая» привязка). Когда вы пытаетесь добавить объект LDAP, это, конечно, требуется. Тогда колеса отрываются. (Если вы чувствуете побуждение, вы можете прервать его во время запуска, экспортировав, LD_BIND_NOW=1что отключает отложенное связывание, а затем запускается slapd, хотя шансы - другой символ, отключают его.)
Прямо сейчас самый простой вариант - работать со статическим back_ldap( --enable-ldap=yesи, возможно, make clean && make depend && make installбыть уверенным, что slapdон правильно построен). Менее простой вариант заключается в том, чтобы обойти проблему зависимости и скрестить пальцы в надежде, что у нее нет каких-то странных побочных эффектов.LD_PRELOAD=/usr/lib/libldap.soLD_PRELOAD=/usr/lib/libldap_r.so
Хорошо, это древнее электронное письмо покрывает проблему: http://www.openldap.org/lists/openldap-software/200211/msg00469.html
по умолчанию slapdсвязан со статическим libldap_r.a, это ограничивает символы, которые будут доступны тем, кто известен в время ссылки . Поскольку динамические модули загружаются во время выполнения с dlopen()компоновщиком, они не видят свои требования (символы / библиотеки).
Можно разумно заключить, что динамическое построение (некоторых) бэкэндов в течение некоторого времени было в значительной степени нарушено.
Так что, либо не используйте динамические бэкэнды (рекомендуется), либо поменяйте сборку (не рекомендуется) чем-то вроде:
make depend && make
rm servers/slapd/slapd
LTSTATIC="" make -e # alternative to editing the Makefile
make install
Это связано slapdс тем, что libldap_r.soвы только что создали, вместо того .a, чтобы, так что все символы могут быть загружены при необходимости (это также slapdуменьшает размер диска примерно на 15%). Я не запускал работающий сервер LDAP с этим, YMMV. Должны быть некоторые подобные или альтернативные решения, используемые дистрибутивами ...