Bug 243296 - libebookbackendldap.so not linked against libldap.so
libebookbackendldap.so not linked against libldap.so
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
7
All Linux
low Severity medium
: ---
: ---
Assigned To: Matthew Barnes
:
: 248833 (view as bug list)
Depends On:
Blocks: 248568
  Show dependency treegraph
 
Reported: 2007-06-08 08:55 EDT by Jason T. Greene
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version: 1.10.3.1-2.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-25 01:18:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
openldap.spec PATCH (602 bytes, patch)
2007-06-11 23:45 EDT, Jason T. Greene
no flags Details | Diff
Fixed binary RPM built from patched openldap (3.64 MB, application/octet-stream)
2007-06-19 20:22 EDT, Jason T. Greene
no flags Details
Existing patch for evolution-exchange (2.39 KB, patch)
2007-06-26 23:14 EDT, Matthew Barnes
no flags Details | Diff
Fixes openldap macro in evolution-data-server (957 bytes, patch)
2007-06-27 11:25 EDT, Jason T. Greene
no flags Details | Diff
Patch to acinclude macro (2.39 KB, patch)
2007-06-27 11:26 EDT, Jason T. Greene
no flags Details | Diff

  None (edit)
Description Jason T. Greene 2007-06-08 08:55:40 EDT
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
Comment 1 Jason T. Greene 2007-06-08 09:00:12 EDT
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
Comment 2 Matthew Barnes 2007-06-08 09:36:06 EDT
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?
Comment 3 Jason T. Greene 2007-06-08 13:40:39 EDT
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

Comment 4 Matthew Barnes 2007-06-08 17:08:41 EDT
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
Comment 5 Jason T. Greene 2007-06-11 23:45:29 EDT
Created attachment 156775 [details]
openldap.spec PATCH
Comment 6 Jason T. Greene 2007-06-11 23:51:50 EDT
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
Comment 7 Jason T. Greene 2007-06-19 20:22:44 EDT
Created attachment 157434 [details]
Fixed binary RPM built from patched openldap

Here is a fixed package for other encountering this issue.
Comment 8 Jason T. Greene 2007-06-26 20:37:51 EDT
Should I reassign this to the openldap project?
Comment 9 Matthew Barnes 2007-06-26 23:07:55 EDT
(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.
Comment 10 Matthew Barnes 2007-06-26 23:14:52 EDT
Created attachment 157979 [details]
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.
Comment 11 Jason T. Greene 2007-06-27 11:25:01 EDT
Created attachment 158023 [details]
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.
Comment 12 Jason T. Greene 2007-06-27 11:26:33 EDT
Created attachment 158024 [details]
Patch to acinclude macro
Comment 13 Matthew Barnes 2007-06-27 12:02:33 EDT
(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.
Comment 14 Jason T. Greene 2007-06-27 13:05:23 EDT
No worries ;)
Comment 15 Phil Hale 2007-07-03 19:02:21 EDT
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.
Comment 16 Matthew Barnes 2007-07-17 13:37:38 EDT
Fixed in evolution-data-server-1.10.3.1-2.fc7 and 1.11.5-2.fc8.

I've also cloned this bug for RHEL5.  See bug #248568.
Comment 17 Fedora Update System 2007-07-18 16:52:11 EDT
evolution-data-server-1.10.3.1-2.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Henrik Nordström 2007-07-18 23:59:03 EDT
*** Bug 248833 has been marked as a duplicate of this bug. ***
Comment 19 Fedora Update System 2007-07-25 01:18:43 EDT
evolution-data-server-1.10.3.1-2.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

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