/******************************************************************************
* Copyright (C) 1999, 2000 Novell, Inc. All Rights Reserved.
*
* THIS WORK IS SUBJECT TO U.S. AND INTERNATIONAL COPYRIGHT LAWS AND
* TREATIES. USE, MODIFICATION, AND REDISTRIBUTION OF THIS WORK IS SUBJECT
* TO VERSION 2.0.1 OF THE OPENLDAP PUBLIC LICENSE, A COPY OF WHICH IS
* AVAILABLE AT HTTP://WWW.OPENLDAP.ORG/LICENSE.HTML OR IN THE FILE "LICENSE"
* IN THE TOP-LEVEL DIRECTORY OF THE DISTRIBUTION. ANY USE OR EXPLOITATION
* OF THIS WORK OTHER THAN AS AUTHORIZED IN VERSION 2.0.1 OF THE OPENLDAP
* PUBLIC LICENSE, OR OTHER PRIOR WRITTEN CONSENT FROM NOVELL, COULD SUBJECT
* THE PERPETRATOR TO CRIMINAL AND CIVIL LIABILITY.
******************************************************************************/
macros into our namespace and limit use to headers. A subsequent
round will add macros to separately handle forward declarations
of variables from declaration of function prototypes. The last
round will add additional macros for declaring actual variables and
functions.
was only of limited use with LDAPv2 (worked okay if no non-T.61
values existed) but downright dangerous in the face of LDAPv3.
Any translation must be schema aware and the BER isn't.
modules are dynamically loaded, they summon libldap when needed.
However, depending on the security libraries available when the
shared libldap was built, the latter brings up other dependencies.
On some platforms, it seems that no solution is available: no
indirect dynamic dependencies. But for some platforms where this
is supported (in particular, Linux), the shared libldap must
contain info on what other dynamic libraries it needs. We were
failing to put this info into the shared library. This patch
seems to fix it.
