Disconnecting -lldap from utilizing apr-util

[William A. Rowe, Jr.]

http://people.apache.org/~wrowe/ldap/apr-util-1.x-ldap.patch

is the very first draft of a proposal which begins to break apart the
libldap (& liblber) bindings from the core libaprutil-1 and consuming
applications.

You can see, for reference, an earlier patch in that tree that broke ldap
from httpd 2.0.  Remember than in libaprutil-0, there was no code that
actually consumed the ldap libs in apr-util; this was all the problem of
the user who linked to apr-util.  So the earlier set of patches allowed
httpd to bind -lldap into mod_ldap and mod_auth_ldap on an explicit basis.

http://people.apache.org/~wrowe/ldap/httpd-2.x-ldap.patch illustrates how
this translates for such a patched apr-util-1.

What is interesting is that a patched apr-1.3.x remains binary compatible.
Simply ./configuring --enable-dbd-dso (really should be --enable-dsos) in
combination with --with-ldap will toggle the behavior.

What breaks in terms of ***build*** behavior is that it becomes the user's
responsibility to add the result of `apu-1-config --ldap-libs` to the app's
ld bindings.  Otherwise, the non-ldap-consuming app won't have a direct
binding to libldap.  Which IMHO is how it always should be.

The question is - is this a permitted change in 1.3.0?  I believe it is, we
should not have been in the business of providing libraries in the manner
that happened for ldap.  The other accessors, expat, iconv, etc don't carry
this sort of communicative property for our util users.  In short, it was
a failed contract that should be harmonized without disrupting our users
too terribly.  The --ldap-libs query lets them resume.

But this is not far enough, and only phase 1 of a patch.  The complete
patch should abstract the rest of the ldap provider such that they do not
need to bind to -lldap in the first place.  If this is not the goal, I'd
argue that this ldap binding really wasn't appropriate in the first place.
[Of course, that's an argument for 2.0 sans ldap and not a solution for 1.3
next release ;-]  But I didn't want to hold up discussing a patch just to
add stubs to apr_ldap_err2string etc etc.

I also didn't hold up to add the parsing of LD_LIBRARY_PATH etc to find the
libraries (ldap, and dbd as well).  That's something to discuss as well, and
again not a reason to hold up this patch.

Folks had hoped that httpd-2.2.9 would be compatible with either 1.2 or 1.3
apr flavors.  We can get closer by improving the config.m4 patches, e.g.

MOD_AUTHNZ_LDAP_LDADD="`$apu_config --ldap-libs`"

becomes

MOD_AUTHNZ_LDAP_LDADD="`$apu_config --ldap-libs`" \
    || MOD_AUTHNZ_LDAP_LDADD=""

meaning that when --ldap-libs is unrecognized, we surrender to the complete
libs exposed by apr-util-1.2.x.  But this would only be a provisional change
for the lifespan of httpd-2.2.x until it absolutely requires 1.3.0.

This does create a hardship for ldap users of apr-util _ldap API, but with
consideration given to the many, many applications of apr-util which don't
utilize the _ldap API, this change seems very appropriate to me.  The note
about --ldap-libs can be prominently listed as the first entry in CHANGES.

Comments, feedback or questions?

Bill