https://bugs.openldap.org/show_bug.cgi?id=9229
Bug ID: 9229 Summary: Make liblutil usable by libldap Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs@openldap.org Reporter: ryan@openldap.org Target Milestone: ---
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.
https://bugs.openldap.org/show_bug.cgi?id=9229
Ryan Tandy ryan@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9001, | |https://bugs.openldap.org/s | |how_bug.cgi?id=6517, | |https://bugs.openldap.org/s | |how_bug.cgi?id=9228
https://bugs.openldap.org/show_bug.cgi?id=9229
Ryan Tandy ryan@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.6.0
--- Comment #1 from Ryan Tandy ryan@openldap.org --- Also audit and make sure all link commands follow the pattern:
-lldap -llutil -llber
(liblutil already depends on liblber)
https://bugs.openldap.org/show_bug.cgi?id=9229
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.0 |2.7.0 Assignee|bugs@openldap.org |ondra@mistotebe.net
--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org --- Ondrej to investigate merging into libldap for 2.7
https://bugs.openldap.org/show_bug.cgi?id=9229
--- Comment #3 from Ondřej Kuzník ondra@mistotebe.net --- 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.
https://bugs.openldap.org/show_bug.cgi?id=9229
--- Comment #4 from Ondřej Kuzník ondra@mistotebe.net --- Ran a few queries on Debian's codesearch (best one seems to be https://codesearch.debian.net/search?literal=0&perpkg=1&q=%5Cblutil_...). It seems we should be safe to expose them just fine (only lutil_sasl_interact is actually present and it's basically ours).
https://bugs.openldap.org/show_bug.cgi?id=9229
--- Comment #5 from Howard Chu hyc@openldap.org --- Ryan, can you give a list of the actual liblutil functions you have a use for?
https://bugs.openldap.org/show_bug.cgi?id=9229
--- Comment #6 from Ondřej Kuzník ondra@mistotebe.net --- 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?).
https://bugs.openldap.org/show_bug.cgi?id=9229
Ondřej Kuzník ondra@mistotebe.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|ondra@mistotebe.net |bugs@openldap.org
--- Comment #7 from Ondřej Kuzník ondra@mistotebe.net --- This is shelved for now, but the work is mostly done here: https://git.openldap.org/ondra/openldap/-/tree/its9229
https://bugs.openldap.org/show_bug.cgi?id=9229
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |SUSPENDED Target Milestone|2.7.0 |--- Status|UNCONFIRMED |RESOLVED
https://bugs.openldap.org/show_bug.cgi?id=9229
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
-
openldap-its＠openldap.org