liblutil is a static library (non-PIC) and so cannot be linked into shared objects, however we have several use cases for reusing its code in libldap. Some options: - moving more code from liblutil to libldap - just merge the whole thing? - are there components that link liblutil but _not_ libldap? - build liblutil as PIC (take a minor performance hit when linked into programs?) - build liblutil twice (liblutil.a and liblutil_pic.a) - symlink liblutil sources into libldap build dir, like libldap_r does with libldap - both of these last options require checking whether executables can call the PIC symbols safely (if some symbols are used by both library and program code) Nice-to-have for 2.5, I'd say more likely for 2.6 at this point.
Also audit and make sure all link commands follow the pattern: -lldap -llutil -llber (liblutil already depends on liblber)
Ondrej to investigate merging into libldap for 2.7
So I've been looking into moving the majority of liblutil into libldap. Saying majority because there's some things that would be a little awkward: - we carry some crypto implementations (md5, sha1), maybe it's time we required a crypto library of some sort for that? Then those could go altogether - ntservice.c and slapmsg collection might move into servers/slapd instead - some symbol presence is potentially volatile which doesn't mesh well with libldap symbol versioning: - again NT (ifdef HAVE_NT_SERVICE_MANAGER, HAVE_NT_EVENT_LOG) - HAVE_LONG_LONG (lutil_atollx and HASH64*) - memcmp/getpeereuid and a few more stand-ins We can probably drop some (memcmp at least) since libldap has relied on libc providing them for some time already. If we can't, a little of that might have to stay in liblutil that's still a static library. After it is done and we're happy with it, we'll update the link script to include the new symbols saying they exist as of LIBLDAP2.201, that's the easy bit. I've started on a little cleanup (getting rid of code behind/using macros that never existed in VCS, memcmp, ...) that can get in soon regardless of whether we've decided on the above.
Ran a few queries on Debian's codesearch (best one seems to be https://codesearch.debian.net/search?literal=0&perpkg=1&q=%5Cblutil_+-package%3Aopenldap). It seems we should be safe to expose them just fine (only lutil_sasl_interact is actually present and it's basically ours).
Ryan, can you give a list of the actual liblutil functions you have a use for?
From memory, base64 support was what started this (probably because of the ldif_* API) but more might have been mentioned (sasl and UUID handling maybe?).
This is shelved for now, but the work is mostly done here: https://git.openldap.org/ondra/openldap/-/tree/its9229