From reading the OpenLDAP source code the libldap_r build appears toOn Fri, Jan 23, 2009 at 07:10:36AM -0500, Jeff Trawick wrote:
> On Fri, Jan 23, 2009 at 7:00 AM, Eric Covener <email@example.com> wrote:
> > On Fri, Jan 23, 2009 at 3:46 AM, Graham Leggett <firstname.lastname@example.org> wrote:
> > > This is the first time I have heard of ldap_r. Is there a reason why we
> > > can't just try bind to ldap_r first, and if that fails fall back to ldap?
> > I think that's the way to go.
> Yeah, sounds right.
> FWIW, /usr/sbin/httpd.worker on RHEL 5 U2 loads just plain libldap (and
> libldap_r is a distinct, and larger, library). A naive observer (okay, me)
> would have expected that to be an explosive combination that would have been
> fixed long ago.
compile in a bunch of mutex locking calls around many/most of the ldap_*
It's not obvious to me whether:
a) this is because those calls are in fact manipulating process-global
state in some thread-unsafe way (not obvious how, if so), or
b) this is enabling an additional API guarantee, that concurrent use of
a single LDAP * object from multiple threads is safe.
I would assume any user of this apr-util API, hahaha sorry, let me start
again.... I would assume that httpd does not rely on the additional API
guarantee in (b).
Since libldap and libldap_r seem to implement the same set of symbols
(and without symbol versioning) this kind of issue is a minefield for
downstream distributors, if apr-util/httpd link against libldap_r and
some perl LDAP foo links against libldap, everything goes boom.