Re: [PATCH] LDAP support for apr-util

[Justin Erenkrantz <je...@ebuilt.com>]

On Tue, Jul 31, 2001 at 11:10:41AM +0200, Graham Leggett wrote:
> Would APR_ADDTO replace APR_CHECK_LIB? I just used macros that are
> available as part of Autoconf - I am not familiar with any of the APR
> macros.

This line:
    LIBS="-l${ldaplib} ${extralib} $LIBS"
would be replaced with:
    APR_ADDTO(LIBS, "-l${ldaplib} ${extralib}")
m4 escaping rules may want it to be (I forget):
    APR_ADDTO(LIBS, [-l\${ldaplib} \${extralib}])

AC_CHECK_LIB stays the same.  This just prevents multiple instances of
the same library from being inserted into the LIBS string (which is a
real annoyance).

> > You will also need to add the -R flags for Solaris (not sure the best
> > way to do this - be nice if APR had a macro like APR_ADDLIB which also
> > added the -R flag when needed).
> 
> What does the -R flag do, and how should it be added?

On Solaris, -R specifies "add this directory to the run-time linker 
search path."  GNU ld has -rpath.  This obviates the need for
LD_LIBRARY_PATH and other hacks.  Wherever you do -L, you should add -R
(only if you are on Solaris).  I'd also do -rpath on Linux, but that's
me.

APR_ADDTO(LDFLAGS, "-L/path/to/lib")
if on Solaris, you also want to do: APR_ADDTO(LDFLAGS, "-R/path/to/lib")
if on Linux, you also want to do: APR_ADDTO(LDFLAGS, "-Wl,-rpath /path/to/lib")

> > > /* LDAP header files */
> > > #if APR_HAVE_LDAP_H
> > > #include <@w...@ldap.h>
> > > #endif
> > > #if APR_HAVE_LBER_H
> > > #include <@w...@lber.h>
> > > #endif
> > > #if APR_HAVE_LDAPSSL_H
> > > #include <@w...@ldap_ssl.h>
> > > #endif
> > 
> > Couldn't we rely on setting CFLAGS/CPPFLAGS correctly instead?
> 
> Do you have an example of how to do this?

If you set the CFLAGS and CPPFLAGS environment variables in your
autoconf script, those directories should be included in the Makefile
when you build.  Therefore, the path in the #include directive is moot.

> The idea behind it is that various lookup and compare operations are
> cached, rather than the results of actual LDAP queries. It has a large
> performance advantage, as often repeated queries (is this
> username/password correct, is this dn a member of this group) are not
> repeated on every hit.

In my experience, LDAP code should be fairly fast.  It really doesn't
even depend on your LDAP server.  I run OpenLDAP on a SparcStation 10 - 
that's not much fun (40MHz CPUs), but the lookups and queries are 
really quick.  On current hardware, this is really a non-issue.

> > If you really want to cache it locally, I'd use anonymous DBMs or
> > something more abstract (i.e. not at this level, but at the level
> > where this code would be called).  I'm not sold on needing to have
> > this cache in the general case.
> 
> I'd like to review this cache stuff down the line - as it currently uses
> malloc() and free(). Either a DBM based or SMS based cache might do the
> trick.
> 
> In the meantime, I am busy trying to hide the cache entirely from the
> caller so we can fiddle on the backend without breaking things.

Yeah, get it in and then let's see if we can remove the need for
caching.  My gut tells me that you won't really want it.  I could be
wrong though.

> > For reliability reasons, you probably want to use asynchronous bindings.
> > 
> > Do:
> > ldap_init
> > ldap_simple_bind
> > ldap_result
> > 
> > If the LDAP server is unreachable, you'll block waiting for the server
> > to respond.  It's really preferable to use asynchronous bindings (I've
> > used 1 second timeouts in the past).
> 
> Hmmm - this is better, yes. Will change this.
> 
> How would this impact locking?

Shouldn't.  

I'd have the API in apr-util be essentially blocking, but the 
underlying implementation may use asynchronous with timeouts.  The 
user of apr-util shouldn't have to deal with the asynchronous crap
(as far as he knows, it is synchronous).  -- justin

Re: [PATCH] LDAP support for apr-util

[Graham Leggett <mi...@sharp.fm>]

Justin Erenkrantz wrote:

> This line:
>     LIBS="-l${ldaplib} ${extralib} $LIBS"
> would be replaced with:
>     APR_ADDTO(LIBS, "-l${ldaplib} ${extralib}")
> m4 escaping rules may want it to be (I forget):
>     APR_ADDTO(LIBS, [-l\${ldaplib} \${extralib}])
> 
> AC_CHECK_LIB stays the same.  This just prevents multiple instances of
> the same library from being inserted into the LIBS string (which is a
> real annoyance).

Ok, makes sense.

The trouble is that the APR_ADDTO macro is not avaiulable to APR-util.
Should it be? Should I just copy the macro out of APR and into APR-util?

> On Solaris, -R specifies "add this directory to the run-time linker
> search path."  GNU ld has -rpath.  This obviates the need for
> LD_LIBRARY_PATH and other hacks.  Wherever you do -L, you should add -R
> (only if you are on Solaris).  I'd also do -rpath on Linux, but that's
> me.
> 
> APR_ADDTO(LDFLAGS, "-L/path/to/lib")
> if on Solaris, you also want to do: APR_ADDTO(LDFLAGS, "-R/path/to/lib")
> if on Linux, you also want to do: APR_ADDTO(LDFLAGS, "-Wl,-rpath /path/to/lib")

Would I specifically have to test for Solaris and then add the -R flag,
or can I get autoconf to do this for me?

> In my experience, LDAP code should be fairly fast.  It really doesn't
> even depend on your LDAP server.  I run OpenLDAP on a SparcStation 10 -
> that's not much fun (40MHz CPUs), but the lookups and queries are
> really quick.  On current hardware, this is really a non-issue.

The code is there, and mature and stable - I'll try do a test both with
and without the cache code to see what a difference it makes.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: [PATCH] LDAP support for apr-util

[Justin Erenkrantz <je...@ebuilt.com>]

On Thu, Aug 02, 2001 at 02:22:53AM +0200, Graham Leggett wrote:
> Doing a grep for "-R" within APR finds this flag only in libtool - can
> libtool be used to make sure the libs are correctly specified?

I was wondering about that today as I was looking through libtool.

So, don't worry about it.  If I want the LDAP libraries to link right
and I need the -R flag, I'll find some way of adding it.  =)
-- justin

Re: [PATCH] LDAP support for apr-util

[Graham Leggett <mi...@sharp.fm>]

Justin Erenkrantz wrote:

> On Solaris, -R specifies "add this directory to the run-time linker
> search path."  GNU ld has -rpath.  This obviates the need for
> LD_LIBRARY_PATH and other hacks.  Wherever you do -L, you should add -R
> (only if you are on Solaris).  I'd also do -rpath on Linux, but that's
> me.
> 
> APR_ADDTO(LDFLAGS, "-L/path/to/lib")
> if on Solaris, you also want to do: APR_ADDTO(LDFLAGS, "-R/path/to/lib")
> if on Linux, you also want to do: APR_ADDTO(LDFLAGS, "-Wl,-rpath /path/to/lib")

Doing a grep for "-R" within APR finds this flag only in libtool - can
libtool be used to make sure the libs are correctly specified?

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."