Исторически в оригинальном OpenLDAP есть ldap-библиотека, которая предназначена для ldap-клиентов, но при этом также используется внутри самого сервера. Кроме этого, есть еще одна библиотека для серверной части и серверных ldap-утилит.В ReOpenLDAP эти две библиотеки были объединены, так как это именно сервер, а предоставление клиентских ldap-библиотек и/или обеспечение совместимости не планировалось, и никогда не входило в цели. Такое объединение позволило устранить избыточность кода, что-то выбросить, что-то починить, переделать и т.д.
Кроме внесения изменений и слияния библиотека также была переименована, что исключает какие-либо конфликты с традиционными библиотеками от OpenLDAP.
---
Отказ от предоставления клиентской ldap-библиотеки в ReOpenLDAP более чем оправдан - грубо говоря там ад, с массой сторонних эффектов и глюков. Код не только очень плохой и не прозрачный, но и небрежно написанный. При починке серверной части многое пришлось резать и переделывать. При этом обеспечить совместимость было крайне сложно (скорее невозможно с учетом side effects), и тем более невозможно было протестировать. С другой стороны, я чинил именно сервер, т.е. не было цели чинить или переписывать клиентскую ldap-библиотеку больше чем нужно для устойчивой работы сервера.
Например, ReOpenLDAP можно собрать с включением hipagut (встроенный чекер памяти), при этом любой клиентский код вместо malloc/free должен использовать hipagut-функции для блоков памяти передаваемых или получаемых от ldap-библиотеки, что невозможно в случае стороннего код использующего библиотеку.
Поэтому никакой совместимости с OpenLDAP быть не может.
---
Что касательно вашей проблемы при сборке - НЕОБХОДИМО и достаточно обеспечить использование правильных include-путей при сборке какого-либо кода использующего ldap:
1. Всё что работает на стороне сервера ReOpenLDAP нужно собирать с заголовочными файлами и библиотеками ReOpenLDAP. Это обеспечивается (проверялось при разработке) при сборке ldap-модулей/плагинов внутри ReOpenLDAP. Поэтому, если вам нужно собрать какой-то сторонний модуль, то (видимо) проще всего добавить его в ReOpenLDAP. Так или иначе, самое главное - не смешивать со вторым пунктом.
2. Всё что работает на клиентской стороне нужно собирать с заголовочными файлами и библиотеками из состава linux-дистрибутива или OpenLDAP. Так или иначе, самое главное - не смешивать с первым пунктом.
---
На всякий:
- OpenLDAP кошмарен. RedHat выбросил это дерьмо из RHEL совершенно оправдано. Чем раньше вы откажитесь от OpenLDAP и его библиотек, тем меньше будет боли.
- ReOpenLDAP гораздо меньшее дерьмо, но всё же устранить проблемы и недостатки можно только переписав код.
Разработка ReOpenLDAP велась для МегаФона и закончена летом 2016. Насколько мне известно, еще (примерно) через год МегаФон начал процесс миграции на Tarantool (что оправдано) и давно завершил его.
А с 2019 я приостановил доработку ReOpenLDAP и перенос исправлений из openLDAP, так как это требовало много времени и ресурсов, при слабой популярности у пользователей.
Поэтому, если требуется поддержка и/или ReOpenLDAP, то нужно искать спонсоров и/или волонтеров.
Тем не менее, при необходимости репликации (тем более multi-master) я рекомендую использовать ReOpenLDAP. Если же репликаций не нужна, то можно взять OpenLDAP, но еще лучше - любой другой ldap-сервер.
