Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Sender: minfrin
Message-ID: <3B67FC02.4A1C642D@sharp.fm>
Date: Wed, 01 Aug 2001 14:54:26 +0200
From: Graham Leggett <minfrin@sharp.fm>
MIME-Version: 1.0
To: Justin Erenkrantz <jerenkrantz@ebuilt.com>
CC: APR Development <dev@apr.apache.org>
Subject: Re: [PATCH] LDAP support for apr-util
References: <3B65DE44.281A3C57@sharp.fm> <20010731004344.H18358@ebuilt.com>
 <3B667611.11DE262A@sharp.fm> <20010801001418.P18358@ebuilt.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
 micalg=sha1; boundary="------------ms9E66AD56075F75D3C640441C"

This is a cryptographically signed message in MIME format.

--------------ms9E66AD56075F75D3C640441C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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..."
--------------ms9E66AD56075F75D3C640441C
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIHyAYJKoZIhvcNAQcCoIIHuTCCB7UCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BcYwggKVMIIB/qADAgECAgMEyOwwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA1MTEwMDE3NDZaFw0wMjA1MTEwMDE3NDZa
MF0xEDAOBgNVBAQTB0xlZ2dldHQxDzANBgNVBCoTBkdyYWhhbTEXMBUGA1UEAxMOR3JhaGFt
IExlZ2dldHQxHzAdBgkqhkiG9w0BCQEWEG1pbmZyaW5Ac2hhcnAuZm0wgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBALX2zJvQ/9l+sCEpkfMNNwtnMcF8vmPM2sRpibT5nR87bYWyLVCt
XXWXU+UyDOkiQJt6UahnmYZV7u40a1/osbNnjHjyNybejOuUFjHYy1gDwjsElnxYbRRA2SZc
CmrZ4V0QFI0ZKuimGryZQj77UroiIV+Qq+v+PaxDEGwiqJqnAgMBAAGjLTArMBsGA1UdEQQU
MBKBEG1pbmZyaW5Ac2hhcnAuZm0wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCO
l5bH8JXuFM+EZi01jfezzKML5iPBHx4BDj/4gl2lXw1t0v6o+9442F6TpnOVAk3LL1KTupvc
HfM+Bn71iWuD8ASCoSsmVpeoCbOv3lPGltrDgywcmM8phZyK1hHLvvJgfd4IMZbuH/rm0ZWp
WjRORFfik8yuO9DgahgjgAhkujCCAykwggKSoAMCAQICAQwwDQYJKoZIhvcNAQEEBQAwgdEx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93
bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g
U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4
MzAwMDAwMDBaFw0wMjA4MjkyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz
dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE
CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJT
QSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7Sbngn
Z4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmF
zVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ
7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwx
LTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOB
gQBzG28mZYv/FTRLWWKK7US+ScfoDbuPuQ1qJipihB+4h2N0HG23zxpTkUvhzeY42e1Q9Dps
NJKs5pKcbsEjAcIJp+9LrnLdBmf1UG8uWLi2C8FQV7XsHNfvF7bViJu3ooga7TlbOX00/LaW
GCVNavSdxcORL6mWuAU8Uvzd6WIDSDGCAcowggHGAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEV
MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRo
YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFs
IEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwTI7DAJBgUrDgMCGgUAoIGGMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDgwMTEyNTQyN1owIwYJKoZIhvcN
AQkEMRYEFHQa8KxlmuS9nlTLj/YDCKKi12NCMCcGCSqGSIb3DQEJDzEaMBgwBwYFKw4DAgcw
DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCC2qSxv5joMD5vdOaoojsPD57OUe0W
qBk5rmMvdoQXH2cI16suMs3yEtWYKGwCJ64OdIu9couUFLs/IkCuYlu31XVS9phJZxz3qDyf
trdwf3JS86nAvMLbKC9d3RaevArOoFX/o626U0ASIfbUghNyWj3Ec/vKnUwIFiXp40pdbQ==
--------------ms9E66AD56075F75D3C640441C--