+++ 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 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 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 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 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 on 2007-06-11 23:45 EST -- Created an attachment (id=156775) openldap.spec PATCH -- Additional comment from jason.greene 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 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 on 2007-06-26 20:37 EST -- Should I reassign this to the openldap project? -- Additional comment from mbarnes 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 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 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 on 2007-06-27 11:26 EST -- Created an attachment (id=158024) Patch to acinclude macro -- Additional comment from mbarnes 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 on 2007-06-27 13:05 EST -- No worries ;) -- Additional comment from phale.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.
Should be fixed now with the rebase to 1.12.
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