+++ This bug was initially created as a clone of Bug #243296 +++
Description of problem:
The addressbook fails because libebookbackendldap.so is not linked against
libldap.so:
+ ldap://XXX:389/ou=Users,dc=redhat,dc=com??one?
/usr/libexec/evolution-data-server-1.10: symbol lookup error:
/usr/lib64/evolution-data-server-1.2/extensions/libebookbackendldap.so:
undefined symbol: ldap_init
# ldd /usr/lib64/evolution-data-server-1.2/extensions/libebookbackendldap.so |
grep -c ldap
0
Version-Release number of selected component (if applicable):
evolution-data-server-1.10.1-1.fc7.x86_64
-- Additional comment from jason.greene@redhat.com on 2007-06-08 09:00 EST --
Workaround for those that run into this:
1) evolution --force-shutdown
2) LD_PRELOAD=/usr/lib64/libldap.so /usr/libexec/evolution-data-server-1.10
3) evolution
-- Additional comment from mbarnes@redhat.com on 2007-06-08 09:36 EST --
It gets statically linked against /usr/lib/evolution-openldap/lib/libldap.a for
its NTLM support. It's possible it's not linking properly on 64-bit arches.
Do you have a way to reproduce the symbol lookup error?
-- Additional comment from jason.greene@redhat.com on 2007-06-08 13:40 EST --
You can reproduce it by just configuring an ldap server and trying to lookup a
contact.
Which file is supposed to be statically linked? Nothing appears to be in this
package:
for i in `rpm -ql evolution-data-server-1.10.1-1.fc7.x86_64 | grep \\\.so |
xargs`; do count=`nm -D $i | grep ldap_ -c`; if [ "$count" -gt 0 ]; then echo
$i':'; nm -D $i | grep ldap_; echo; fi; done
/usr/lib64/evolution-data-server-1.2/extensions/libebookbackendldap.so:
0000000000006240 T e_book_backend_ldap_get_type
000000000000cb10 T e_book_backend_ldap_new
U ldap_abandon
U ldap_add_ext
U ldap_count_values
U ldap_delete_ext
U ldap_err2string
U ldap_first_attribute
U ldap_first_entry
U ldap_free_urldesc
U ldap_get_dn
U ldap_get_option
U ldap_get_values
U ldap_get_values_len
U ldap_init
U ldap_memfree
U ldap_modify_ext
U ldap_msgfree
U ldap_msgid
U ldap_msgtype
U ldap_next_attribute
U ldap_next_entry
U ldap_objectclass_free
U ldap_parse_result
U ldap_result
U ldap_search_ext
U ldap_search_ext_s
U ldap_search_s
U ldap_set_option
U ldap_simple_bind_s
U ldap_start_tls_s
U ldap_str2objectclass
U ldap_unbind
U ldap_url_parse
U ldap_value_free
U ldap_value_free_len
/usr/lib64/libecal-1.2.so.7:
000000331683f6d0 T e_cal_get_ldap_attribute
/usr/lib64/libecal-1.2.so.7.0.1:
000000331683f6d0 T e_cal_get_ldap_attribute
/usr/lib64/libedata-cal-1.2.so.6:
0000003323815a90 T e_cal_backend_get_ldap_attribute
000000332381bd60 T e_cal_backend_sync_get_ldap_attribute
000000332381e2d0 T e_data_cal_notify_ldap_attribute
/usr/lib64/libedata-cal-1.2.so.6.0.1:
0000003323815a90 T e_cal_backend_get_ldap_attribute
000000332381bd60 T e_cal_backend_sync_get_ldap_attribute
000000332381e2d0 T e_data_cal_notify_ldap_attribute
/usr/lib64/libexchange-storage-1.2.so.3:
U ldap_abandon
U ldap_first_entry
U ldap_get_dn
U ldap_get_option
U ldap_get_values
U ldap_get_values_len
U ldap_init
U ldap_memfree
U ldap_modify_ext
U ldap_msgfree
U ldap_parse_result
U ldap_result
U ldap_search_ext
U ldap_set_option
U ldap_simple_bind_s
U ldap_unbind
U ldap_value_free
U ldap_value_free_len
/usr/lib64/libexchange-storage-1.2.so.3.0.0:
U ldap_abandon
U ldap_first_entry
U ldap_get_dn
U ldap_get_option
U ldap_get_values
U ldap_get_values_len
U ldap_init
U ldap_memfree
U ldap_modify_ext
U ldap_msgfree
U ldap_parse_result
U ldap_result
U ldap_search_ext
U ldap_set_option
U ldap_simple_bind_s
U ldap_unbind
U ldap_value_free
U ldap_value_free_len
-- Additional comment from mbarnes@redhat.com on 2007-06-08 17:08 EST --
The custom LDAP library with NTLM support for Evolution is provided by the
openldap-devel package.
$ rpm -ql openldap-devel | grep evolution
/usr/lib/evolution-openldap
/usr/lib/evolution-openldap/README.evolution
/usr/lib/evolution-openldap/include
/usr/lib/evolution-openldap/include/lber.h
/usr/lib/evolution-openldap/include/lber_types.h
/usr/lib/evolution-openldap/include/ldap.h
/usr/lib/evolution-openldap/include/ldap_cdefs.h
/usr/lib/evolution-openldap/include/ldap_features.h
/usr/lib/evolution-openldap/include/ldap_schema.h
/usr/lib/evolution-openldap/include/ldap_utf8.h
/usr/lib/evolution-openldap/include/slapi-plugin.h
/usr/lib/evolution-openldap/lib
/usr/lib/evolution-openldap/lib/liblber.a
/usr/lib/evolution-openldap/lib/libldap.a
/usr/lib/evolution-openldap/lib/libldap_r.a
-- Additional comment from jason.greene@redhat.com on 2007-06-11 23:45 EST --
Created an attachment (id=156775)
openldap.spec PATCH
-- Additional comment from jason.greene@redhat.com on 2007-06-11 23:51 EST --
The problem is that the evolution-data-server build system expects the child
openldap directory to be "lib" in all cases (see EVO_LDAP_CHECK in acinclude).
Since this directory is already installed in /usr/lib64/evolution-openldap,
there isn't much gain in using an architecture specific lib directory. The small
one-line patch which is attached does exactly this.
Alternatively the evolution-data-server build system could be modified to be
more flexible with library location, however if this is the case, then it would
make more sense to refer to the main libldap.a, instead of the specialized
evolution-openldap structure.
Thanks,
-Jason
-- Additional comment from jason.greene@redhat.com on 2007-06-19 20:22 EST --
Created an attachment (id=157434)
Fixed binary RPM built from patched openldap
Here is a fixed package for other encountering this issue.
-- Additional comment from jason.greene@redhat.com on 2007-06-26 20:37 EST --
Should I reassign this to the openldap project?
-- Additional comment from mbarnes@redhat.com on 2007-06-26 23:07 EST --
(In reply to comment #6)
> The problem is that the evolution-data-server build system expects the child
> openldap directory to be "lib" in all cases (see EVO_LDAP_CHECK in acinclude).
Except that we patch that macro to use %{_libdir}/evolution-openldap/%{_lib}.
> Since this directory is already installed in /usr/lib64/evolution-openldap,
> there isn't much gain in using an architecture specific lib directory. The small
> one-line patch which is attached does exactly this.
Yeah, I'm not sure I understand the rationale for using two architecture
specific directory names in the path. The packages were set up this way before
I took over maintenance of Evolution. Still, if you modify openldap you need to
also modify (or disable) the evolution-exchange patch.
> Alternatively the evolution-data-server build system could be modified to be
> more flexible with library location, however if this is the case, then it would
> make more sense to refer to the main libldap.a, instead of the specialized
> evolution-openldap structure.
You can specify the LDAP library location with the configure option:
./configure --with-openldap=/path/to/ldap/library
This is how we currently link to the custom LDAP library.
Again, we link to the custom LDAP library for its NTLM support, which is not
present in the standard LDAP library. Without it, many customers wouldn't be
able to authenticate with their Microsoft Exchange servers.
Perhaps I'm confused, but I still don't see the problem.
-- Additional comment from mbarnes@redhat.com on 2007-06-26 23:14 EST --
Created an attachment (id=157979)
Existing patch for evolution-exchange
Just hoping this clarifies the situation a bit.
This is the patch that currently gets applied to the EVO_LDAP_CHECK macro. It
replaces the hard-coded "lib" subdirectory with an architecture specific name,
which corresponds to the openldap package.
-- Additional comment from jason.greene@redhat.com on 2007-06-27 11:25 EST --
Created an attachment (id=158023)
Fixes openldap macro in evolution-data-server
The problem is that the patch you mention is only applied to the exchange
connector build, and not the evolution-data-server build. I have attached a
patch to the specfile that adds it.
-- Additional comment from jason.greene@redhat.com on 2007-06-27 11:26 EST --
Created an attachment (id=158024)
Patch to acinclude macro
-- Additional comment from mbarnes@redhat.com on 2007-06-27 12:02 EST --
(In reply to comment #11)
> The problem is that the patch you mention is only applied to the exchange
> connector build, and not the evolution-data-server build. I have attached a
> patch to the specfile that adds it.
Ah, I'm on the same page with you now. Sorry about my thick headedness.
-- Additional comment from jason.greene@redhat.com on 2007-06-27 13:05 EST --
No worries ;)
-- Additional comment from phale@zues.tamucc.edu on 2007-07-03 19:02 EST --
I can confirm this issue with evolution-2.10.2-3.fc7 and
evolution-data-server-1.10.2-3.fc7 on my Fedora 7 x86_64 system. When I
configure a connection to my OpenLDAP server I never get prompted for the LDAP
authentication password, and subsequently can't conduct a search. If I deploy
the work-a-round mentioned in comment # 1 and restart both evolution-data-server
and evolution the prompt comes up and I can successfully connect and search my
OpenLDAP server. I've written a small shell script start-eds.sh with the above
work-a-round and have it start on login to Gnome to get this working.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
release.

Suzanne, here's a quick way to reproduce this:
$ nm /usr/lib/debug/usr/lib/evolution-data-server-1.2/extensions \
/libebookbackendldap.so.debug | grep " ldap_init$"
In 5.1 this will come back empty. In 5.2 you should see "ldap_init".
It indicates that libldap.a from openldap-evolution-devel is linked in.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
http://rhn.redhat.com/errata/RHBA-2008-0361.html

Note

You need to
log in
before you can comment on or make changes to this bug.