1:34 a.m.
Ilya and Volker -
OK. I'm going to ask the two of you to resolve this. Ilya, can you
please describe exactly how the 21.4.17 configure.in fails for you and
on what platforms? Volker, please describe why the 21.4.18 version
doesn't work for you. Maybe in this way, we can get a version that
works for both of you for 21.4.19. Please follow up ASAP so we can
try out potential solutions.
Thank you,
Vin Shelton
---------- Forwarded message ----------
From: Dr. Volker Zell <Dr.Volker.Zell(a)oracle.com>
Date: Dec 10, 2005 12:53 PM
Subject: Re: Updated:
xemacs-21.4.18-1/xemacs-tags-21.4.18-1/xemacs-emacs-common-21.4.18-1
To: Vin Shelton <acs(a)xemacs.org>
>>>> Vin Shelton writes:
On 12/9/05, Dr. Volker Zell <Dr.Volker.Zell(a)oracle.com> wrote:
> Actually there is a cygwin specific patch, the one in configure.in.
> Because when you configure with ldap support, -llber doesn't get included
> during linking. This was the case in the previous version. Only recently
> someone changed the configure stuff for openldap again :-(
I thought this patch:
-- Fix: configure works again when -ldap is specified and -lber
is required.
was supposed to fix that problem. Please send me whatever patch is
required and I'll get the patch into 21.4.19.
Actually the configure magic to detect openldap in 21.4.17 was perfect
for cygwin. I don't know why it got changed on 21.4.18.
For reference here the relevant parts from configure.in in both
versions:
--------------------------------- This is the GOOD one from 21.4.17
-----------------------
dnl Autodetect LDAP
AC_CHECKING(for LDAP)
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) }
fi
if test "$with_ldap" = "yes"; then
AC_DEFINE(HAVE_LDAP)
XE_ADD_OBJS(eldap.o)
if test "$with_ldap_des" = "yes" ; then
XE_PREPEND(-ldes, LIBS)
fi
if test "$with_ldap_krb" = "yes" ; then
XE_PREPEND(-lkrb, LIBS)
fi
if test "$with_ldap_lber" = "yes" ; then
XE_PREPEND(-llber, LIBS)
fi
XE_PREPEND(-lldap, LIBS)
AC_CHECK_FUNCS(ldap_set_option ldap_get_lderrno ldap_result2error
ldap_parse_result)
fi
--------------------------------
and now the new one which breaks under cygwin:
--------------------------------- This is the one from 21.4.18
-----------------------
dnl Autodetect LDAP
AC_CHECKING(for LDAP)
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 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)
XE_ADD_OBJS(eldap.o)
LIBS="$ldap_libs $LIBS"
AC_CHECK_FUNCS(ldap_set_option ldap_get_lderrno ldap_result2error
ldap_parse_result)
fi
---------------------------------
21.5.23 seems to have the same magic as 21.4.17 so I don't see the point
of the change in 21.4.18
For the cygwin version I just reverted to the 21.4.17 stuff.
Regards,
Vin
Ciao
Volker
--
Whoever you are, no matter how lonely,
the world offers itself to your imagination,
calls to you like the wild geese, harsh and exciting--
over and over announcing your place
in the family of things. Mary Oliver
9:47 a.m.
>>>> Vin Shelton writes:
Ilya and Volker -
Hi
OK. I'm going to ask the two of you to resolve this. Ilya, can
you
please describe exactly how the 21.4.17 configure.in fails for you and
on what platforms? Volker, please describe why the 21.4.18 version
doesn't work for you. Maybe in this way, we can get a version that
works for both of you for 21.4.19. Please follow up ASAP so we can
try out potential solutions.
Here is what I get when linking xemacs with 21.4.18 (undefined reference to
`_ber_pvt_opt_on'):
gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wsign-compare
-fno-strict-aliasing -Wshadow -Wpointer-arith -Demacs -I. -DHAVE_CONFIG_H
-Wno-sign-compare -fno-caller-saves -I/usr/X11/include dump-id.c
gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wsign-compare
-fno-strict-aliasing -Wshadow -Wpointer-arith -L/usr/X11R6/lib -o xemacs abbrev.o
alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o
chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o
doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o filelock.o ntplay.o dumper.o
scrollbar-msw.o menubar-msw.o toolbar-msw.o dialog-msw.o console-msw.o device-msw.o
event-msw.o frame-msw.o objects-msw.o select-msw.o redisplay-msw.o glyphs-msw.o gui-msw.o
balloon_help.o balloon-x.o dragdrop.o eldap.o postgresql.o dgif_lib.o gif_io.o menubar.o
scrollbar.o dialog.o toolbar.o menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o
mule.o mule-ccl.o mule-charset.o file-coding.o input-method-xlib.o realpath.o getloadavg.o
inline.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o
cm.o terminfo.o event-unixoid.o databas!
e.o process-unix.o event-stream.o extents.o faces.o fileio.o filemode.o floatfns.o fns.o
font-lock.o frame.o general.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o gutter.o
hash.o imgproc.o indent.o insdel.o intl.o keymap.o line-number.o lread.o lstream.o
macros.o marker.o md5.o minibuf.o objects.o opaque.o print.o process.o profile.o
rangetab.o redisplay.o redisplay-output.o regex.o search.o select.o signal.o sound.o
specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o console-x.o device-x.o
event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o select-x.o xgccache.o widget.o
window.o win32.o xemacs_res.o lastfile.o gmalloc.o vm-limit.o EmacsFrame.o EmacsShell.o
TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o offix.o dump-id.o
../lwlib/liblw.a -lXaw3d -ltiff -lpng -ljpeg -lz -lcompface -lXpm -lXmu -lXt -lXext -lX11
-lSM -lICE -ldb -lncurses -lintl -lpq -lldap -lwinmm -lshell32 -lgdi32 -luser32 -lcomdlg32
-lcomctl32 -lkernel32 -lwinspool
Info: resolving _comp_env by linking to __imp__comp_env (auto-import)
Info: resolving _F by linking to __imp__F (auto-import)
Info: resolving _XtStrings by linking to __imp__XtStrings (auto-import)
Info: resolving _XtShellStrings by linking to __imp__XtShellStrings (auto-import)
Info: resolving _applicationShellWidgetClass by linking to
__imp__applicationShellWidgetClass (auto-import)
Info: resolving _colorConvertArgs by linking to __imp__colorConvertArgs (auto-import)
Info: resolving _shellClassRec by linking to __imp__shellClassRec (auto-import)
Info: resolving _widgetClassRec by linking to __imp__widgetClassRec (auto-import)
Info: resolving __XtInherit by linking to __imp___XtInherit (auto-import)
Info: resolving _wmShellWidgetClass by linking to __imp__wmShellWidgetClass (auto-import)
Info: resolving _topLevelShellClassRec by linking to __imp__topLevelShellClassRec
(auto-import)
Info: resolving _topLevelShellWidgetClass by linking to __imp__topLevelShellWidgetClass
(auto-import)
Info: resolving _transienteldap.o: In function `Fldap_open':
/usr/src/xemacs-21.4.18/src/eldap.c:315: undefined reference to `_ber_pvt_opt_on'
/usr/src/xemacs-21.4.18/src/eldap.c:318: undefined reference to `_ber_pvt_opt_on'
ShellClassRec by linking to __imp__transientShellClassRec (auto-import)
Info: resolving _transientShellWidgetClass by linking to __imp__transientShellWidgetClass
(auto-import)
Info: resolving _compositeClassRec by linking to __imp__compositeClassRec (auto-import)
Info: resolving __XtInheritTranslations by linking to __imp___XtInheritTranslations
(auto-import)
Info: resolving _overrideShellWidgetClass by linking to __imp__overrideShellWidgetClass
(auto-import)
Info: resolving _dialogWidgetClass by linking to __imp__dialogWidgetClass (auto-import)
Info: resolving _commandWidgetClass by linking to __imp__commandWidgetClass (auto-import)
Info: resolving _shellWidgetClass by linking to __imp__shellWidgetClass (auto-import)
collect2: ld returned 1 exit status
And here is a diff between the configure runs of 21.4.17 and 21.4.18:
---
/usr/local/objs/release/xemacs/xemacs-21.4.17/xemacs-21.4.17-1-CONFIGURE.LOG 2005-05-03
22:01:27.056250000 +0200
+++ xemacs-21.4.18-2-CONFIGURE.LOG 2005-12-12 10:37:56.114502400 +0100
checking for LDAP
checking for ldap.h... yes
checking for lber.h... yes
-checking for ldap_search in -lldap... yes
-checking for ber_pvt_opt_on in -llber... yes
+checking for ldap_open... no
+checking for ldap_open in -lldap... yes
checking for ldap_set_option... yes
checking for ldap_get_lderrno... no
checking for ldap_result2error... yes
So it looks like we have to check explicitly for ber_pvt_opt_on in
-llber again.
Thank you,
Vin Shelton
Ciao
Volker
4:41 p.m.
If `eldap.c' line numbers are the same as in upstream 21.4, reference
to `_ber_pvt_opt_on' are created by *some* of `ldap_set_option' calls.
Did not try to provide for such an ldap headers. Would like to see c
preprocessor output for that build configuration. What ldap interface
symbol expands to such a reference?
So it looks like we have to check explicitly for ber_pvt_opt_on in
-llber again.
Or to try to compile and link exactly that code, and see what
libraries are required. This is certainly cleaner than explicit
checks for symbols that are non necessarily for explicit use at all.
This is how going to patch `configure.{in,ac}'.
1:50 a.m.
Ilya N. Golubev wrote:
If `eldap.c' line numbers are the same as in upstream 21.4,
reference
to `_ber_pvt_opt_on' are created by *some* of `ldap_set_option' calls.
Did not try to provide for such an ldap headers. Would like to see c
preprocessor output for that build configuration. What ldap interface
symbol expands to such a reference?
>So it looks like we have to check explicitly for ber_pvt_opt_on in
>-llber again.
>
>
Or to try to compile and link exactly that code, and see what
libraries are required. This is certainly cleaner than explicit
checks for symbols that are non necessarily for explicit use at all.
true, but keep in mind that configure needs to be as defensive as
possible, and this takes precedence over code cleanliness.
10:08 a.m.
>>>> "vin" == Vin Shelton
<acs(a)alumni.princeton.edu> writes:
vin> From: Dr. Volker Zell <Dr.Volker.Zell(a)oracle.com>
vz> 21.5.23 seems to have the same magic as 21.4.17 so I don't
vz> see the point of the change in 21.4.18
I haven't seen any complaints about the logic in 21.5, so that patch is
in the queue at nice +20. The patch has not been rejected, however.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
1:30 p.m.
On 12/12/05, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
>>>>> "vin" == Vin Shelton
<acs(a)alumni.princeton.edu> writes:
vin> From: Dr. Volker Zell <Dr.Volker.Zell(a)oracle.com>
vz> 21.5.23 seems to have the same magic as 21.4.17 so I don't
vz> see the point of the change in 21.4.18
I haven't seen any complaints about the logic in 21.5, so that patch is
in the queue at nice +20. The patch has not been rejected, however.
Stephen,
I'm not sure whether you're talking about 21.5's support of autoconf
2.59 (in which case I presume you were joking) or the ldap/lber
problem in 21.4. As fars as ldap/lber configuration is concerned,
21.4.17 actually had the 'same magic' that currently exists in 21.5,
but Ilya said I was 'too hasty' in applying it because it broke some
configurations. It appears I was again too hasty in applying his fix
for 21.4.18.
Ilya, to make my position clear - I plan to revert to the 21.4.17
ldap/lber configure.in detection support unless someone generates a
patch that claims to work on both cygwin and whatever platform wasn't
working for you (freebsd?).
Regards,
Vin
8:36 a.m.
>>>> "vin" == Vin Shelton <acs(a)xemacs.org>
writes:
vin> As fars as ldap/lber configuration is concerned, 21.4.17
vin> actually had the 'same magic' that currently exists in 21.5,
vin> but Ilya said I was 'too hasty' in applying it because it
vin> broke some configurations.
Right, that's what I had planned to look at, making the change to
behave as Ilya wants 21.4 to behave. Looks like Volker has things
under control, though.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
4:15 p.m.
I haven't seen any complaints about the logic in 21.5,
They were in
<http://list-archive.xemacs.org/xemacs-beta/200411/msg00557.html>
posted on Fri, 26 Nov 2004 22:57:47 +0300
(<027c41a78aba26-gin(a)mo.msk.ru>).
5:40 p.m.
>>>> "Ilya" == Ilya N Golubev
<gin(a)mo.msk.ru> writes:
> I haven't seen any complaints about the logic in 21.5,
Ilya> They were in
Ilya> <http://list-archive.xemacs.org/xemacs-beta/200411/msg00557.html>
Ilya> posted on Fri, 26 Nov 2004 22:57:47 +0300
Ilya> (<027c41a78aba26-gin(a)mo.msk.ru>).
You complained, I asked what you suggest be done, you dropped the
thread, I forgot about it. Sorry.
In your other recent post you write
Ilya> Never tried to figure out, whether that depends on dynamic
Ilya> linker features, or openldap version, or both (newer
Ilya> openldap making use of newer dynamic linker features).
Ilya> Anyway, can not expect linking with `-lldap' only to succeed
Ilya> on all systems.
21.5's configure makes no such assumption; in fact it tests for
several auxiliary libraries and makes a special extra test for -llber.
If that doesn't work on your system, there's not much I can do,
because it works on Mac OS X and it works on Debian Linux, and it
works on Cygwin (what Volker maintains). You need to tell us what
will work on your system, or at least help us figure it out.
For starters, tell us what undefined symbols you're getting; we could
try testing for them the same way we already test for 'ber_pvt_opt_on'.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
4:14 p.m.
describe exactly how the 21.4.17 configure.in fails for you and
on what platforms?
Just the same way as described in
<http://list-archive.xemacs.org/xemacs-beta/200411/msg00557.html>
posted on Fri, 26 Nov 2004 22:57:47 +0300
(<027c41a78aba26-gin(a)mo.msk.ru>).
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.
In 21.4 it is exactly the same, since that 21.5 change was copied into
21.4 (stable) branch without any correction, as pointed out in
<http://list-archive.xemacs.org/xemacs-patches/200502/msg00225.html>
posted on Thu, 24 Feb 2005 22:40:07 +0300
(<027e421e2d9664-gin(a)mo.msk.ru>).
As for platforms, one requiring `-lldap -llber' was asplinux 7.1 on
i386, with openldap bundled with it. In other linux-gnu systems
linking with `-lldap' only may succeed, including mandrakelinux 10.0
on i386. Never tried to figure out, whether that depends on dynamic
linker features, or openldap version, or both (newer openldap making
use of newer dynamic linker features). Anyway, can not expect linking
with `-lldap' only to succeed on all systems.
Anyway, can easily reproduce the failure by writing a script that is
used in place of compiler and always fails if `-lldap' without
`-llber' is passed to it. Actually used such a script to debug. Will
post it on request.
Would like to see `config.log' entries on ldap configuation on
Volker's system, whatever it is. What value would old / 21.4.17
`configure' code assign to `LIBS' on that system?
6703
days inactive
6705
days old
9 comments
6 participants
participants (6)
-
Ben Wing -
Dr. Volker Zell -
Ilya N. Golubev -
Stephen J. Turnbull -
Vin Shelton -
Vin Shelton