A `configure' lossage was introuced in 21.5 branch by revision 1.232
of `configure.in'. On 27 Nov 2004 05:54:42 GMT Ben Wing wrote
(<20041127055442.19012.qmail(a)666.com>, cc: <xemacs-beta(a)xemacs.org>)
about it:
this is my bad. i tried to fix a problem recently and broke things
when --with-ldap is explicitly given.
On 2005/01/23 16:22:57 GMT you (vins) committed the same changes that
broke 21.5, without any fix, in 21.4 branch as revision 1.151.2.30.
Now `configure' in 21.4 breaks on the same systems and for the same
reasons, as it did after revision 1.232 change in 21.5. Please either
roll back the change in 21.4 or fix it both there and in 21.5.
If choose to do the latter. <ldap -llber lost> posted to
<xemacs-beta(a)xemacs.org> on Fri, 26 Nov 2004 22:57:47 +0300
(<027c41a78aba26-gin(a)mo.msk.ru>) described the bug as follows:
Change in revision 1.232 of `configure.in' caused lossage in the
following circumstances.
. System ldap applications must be linked with `-lldap -llber'.
Linking with `-lldap' only causes undefined symbol errors.
. `--with-ldap' arg was specified to `configure'.
In this case `configure' fails to detect library that must be linked
to use ldap. `with_ldap' is `yes', and appropriate `AC_CHECK_LIB' is
not called. `with_ldap_lber' left unset, and `ldap_libs' are not set
properly. This breaks further check of ldap toolkit features and
`eldap.c' compilation.
Never checked other ldap toolkits with other sets of required
libraries.
Please decide what should mean that `--with-ldap' was specified by
`configure' caller and what should mean success of some stage of ldap
toolkit auto-detection, and fix the confusion.
Currently fixing it in my local 21.5 branch as follows.
2004-12-20 Ilya N. Golubev <gin(a)mo.msk.ru>
* configure.in: Fix ldap libraries configuration lossage when
`-lldap -llber' links and but `-lldap' does not; the lossage was
introduced in revision 1.232. Also allow `ldap_libs' to be empty
or overridden by builder.
--- configure.in 12 Dec 2004 03:19:04 -0000 1.18
+++ configure.in 19 Dec 2004 21:10:02 -0000 1.19
@@ -3595,36 +3595,64 @@
dnl Autodetect LDAP
AC_CHECKING(for LDAP)
-ldap_libs=
test -z "$with_ldap" && { AC_CHECK_HEADER(ldap.h, ,with_ldap=no) }
test -z "$with_ldap" && { AC_CHECK_HEADER(lber.h, ,with_ldap=no) }
-if test "$with_ldap" != "no"; then
- AC_CHECK_LIB(ldap, ldap_search, with_ldap=yes)
- dnl Check for other libraries we need to link with to get the main routines.
- test "$with_ldap" != "yes" && { AC_CHECK_LIB(ldap,
ldap_open, [with_ldap=yes with_ldap_lber=yes], , -llber) }
- test "$with_ldap" != "yes" && { AC_CHECK_LIB(ldap,
ldap_open, [with_ldap=yes with_ldap_lber=yes with_ldap_krb=yes], , -llber -lkrb) }
- test "$with_ldap" != "yes" && { AC_CHECK_LIB(ldap,
ldap_open, [with_ldap=yes with_ldap_lber=yes with_ldap_krb=yes with_ldap_des=yes], ,
-llber -lkrb -ldes) }
- dnl Recently, we need -lber even though the main routines are elsewhere,
- dnl because otherwise be get link errors w.r.t. ber_pvt_opt_on. So just
- dnl check for that (it's a variable not a fun but that doesn't seem to
- dnl matter in these checks) and stick in -lber if so. Can't hurt (even to
- dnl stick it in always shouldn't hurt, I don't think) ... #### Someone who
- dnl #### understands LDAP needs to fix this properly.
- test "$with_ldap_lber" != "yes" && { AC_CHECK_LIB(lber,
ber_pvt_opt_on, with_ldap_lber=yes) }
+if test no != "$with_ldap";then
+ if test . != "${ldap_libs+.}";then
+ ldap_libs=
+ AC_CHECK_FUNC(ldap_open,dnl Allow it to be in generic "$LIBS"
+ [with_ldap=yes
+ test yes = "$extra_verbose" &&
+ echo "Setting ldap_libs to $ldap_libs"],dnl
+ [AC_CHECK_LIB(ldap, ldap_open,dnl
+ [with_ldap=yes],dnl
+ [ldap_needs_lber=yes ldap_other_libs=-llber
+dnl This requires `AC_CACHE_VAL' (which is called by `AC_CHECK_LIB')
+dnl to be redefined to ignore cached (shell variable) value, as it is
+dnl done above, because the same variable is used in all
+dnl `AC_CHECK_LIB' expansions in macro invocation below. Worse, if it
+dnl is not done, there is no portable way to compensate for this
+dnl locally since `unset' command is not supported by all shells. The
+dnl other solution would be changing `AC_CHECK_LIB' so that cache
+dnl variable name depends on the macro OTHER-LIBRARIES argument.
+ AC_CHECK_LIB(ldap, ldap_open,dnl
+ [with_ldap=yes],dnl
+ [ldap_needs_krb=yes ldap_other_libs="$ldap_other_libs -lkrb"
+ AC_CHECK_LIB(ldap, ldap_open,dnl
+ [with_ldap=yes],dnl
+ [ldap_needs_des=yes ldap_other_libs="$ldap_other_libs -ldes"
+ AC_CHECK_LIB(ldap, ldap_open,dnl
+ [with_ldap=yes],dnl
+ [with_ldap=no],dnl
+ $ldap_other_libs)],dnl
+ $ldap_other_libs)],dnl
+ $ldap_other_libs)])
+ if test yes = "$with_ldap";then
+ if test yes = "$ldap_needs_des";then
+ XE_PREPEND(-ldes, ldap_libs)
+ fi
+ if test yes = "$ldap_needs_krb";then
+ XE_PREPEND(-lkrb, ldap_libs)
+ fi
+ if test yes = "$ldap_needs_lber";then
+ XE_PREPEND(-llber, ldap_libs)
+ fi
+ XE_PREPEND(-lldap, ldap_libs)
+ fi])
+ else
+dnl Allow builder to override "$ldap_libs".
+ save_LIBS="$LIBS" LIBS="$ldap_libs $LIBS"
+ AC_CHECK_FUNC(ldap_open,dnl
+ [with_ldap=yes
+ test yes = "$extra_verbose" &&
+ echo "Setting ldap_libs to $ldap_libs"],dnl
+ [with_ldap=no])
+ LIBS="$save_LIBS"
+ fi
fi
if test "$with_ldap" = "yes"; then
AC_DEFINE(HAVE_LDAP)
- if test "$with_ldap_des" = "yes" ; then
- XE_PREPEND(-ldes, ldap_libs)
- fi
- if test "$with_ldap_krb" = "yes" ; then
- XE_PREPEND(-lkrb, ldap_libs)
- fi
- if test "$with_ldap_lber" = "yes" ; then
- XE_PREPEND(-llber, ldap_libs)
- fi
- XE_PREPEND(-lldap, ldap_libs)
- save_LIBS="$LIBS" LIBS="$LIBS $ldap_libs"
+ save_LIBS="$LIBS" LIBS="$ldap_libs $LIBS"
AC_CHECK_FUNCS(ldap_set_option ldap_get_lderrno ldap_result2error ldap_parse_result)
LIBS="$save_LIBS"
XE_APPEND(modules/ldap, MAKE_SUBDIR)