When upgrading from 2.1.x to 2.2.x, OpenLDAP's own binaries and libraries get linked against liblber.so.2 which isn't provided by 2.2.x. Re-emerging OpenLDAP a second time right away fixes the problem. This shouldn't happen... Reproducible: Always Steps to Reproduce: revdep-rebuild example output right after upgrading: broken /usr/bin/ldapmodify (requires liblber.so.2) broken /usr/bin/ldapmodrdn (requires liblber.so.2) broken /usr/bin/ldapadd (requires liblber.so.2) broken /usr/bin/ldappasswd (requires liblber.so.2) broken /usr/bin/ldapsearch (requires liblber.so.2) broken /usr/bin/ldapwhoami (requires liblber.so.2) Sorry for not actual ldd output, but I really, really don't have the time to downgrade again to test it (working under a little personal deadline).
could you please attach your portage logs for the openldap merge?
ok, I can reproduce this now, and I've filed a bug with upstream. http://www.openldap.org/its/index.cgi/Incoming?id=3734
even after emerging it two times, I have to do this in order for apps linked to ldap to work: ln -s /usr/lib/liblber.so /usr/lib/libldap.so.2 ln -s /usr/lib/liblber.so /usr/lib/liblber.so.2
no! do NOT do ln -s /usr/lib/liblber.so /usr/lib/liblber.so.2 - the libraries are NOT completely compatible - some of the symbols have been renamed. I've put in 2.2.26-r1 as a workaround that provides the old liblber.so.2 that is needed (nothing should be linked to libldap.so.2), but after this bug is resolved by upstream, everybody should be using revdep-rebuild more.
*** Bug 93551 has been marked as a duplicate of this bug. ***
*** Bug 94458 has been marked as a duplicate of this bug. ***
emerge is quiet clear about this bug: # tail 2979-openldap-2.2.26-r2.log * machine please see the ebuild for upgrade instructions, otherwise * you may corrupt your database! * Part of the configuration file syntax has changed: * 'access to attribute=' is now 'access to attrs=' * You must also run revdep-rebuild after upgrading from 2.1 to 2.2: * # revdep-rebuild --soname liblber.so.2 * # revdep-rebuild --soname libldap.so.2 * # revdep-rebuild --soname libldap_r.so.2 I agree that other app usually complain the bad wa about this, for example http://forums.gentoo.org/viewtopic-p-2465758.html#2465758 says: configure: error: *** compiler cannot create working executables, check config.log *** but any user reading CAREFULLY his emerge logs and/or using enotice http://dev.gentoo.org/~eldad/enotice/enotice would NOT leave this bug open for more time than required for applying the proposed solution: revdep-rebuild --soname liblber.so.2 && revdep-rebuild --soname libldap.so.2 && revdep-rebuild --soname libldap_r.so.2 and thats all ! Please close this bug.
DoubleHP: I'm waiting for upstream on this, as the openldap binaries themselves get bad linking.
Pierre, you misunderstood the scope of this bug. This bug is not about binaries belonging to other packages not working anymore because of the linkage change in OpenLDAP. That's normal. It's about OpenLDAP's binaries and libraries themselves getting linked to the old already-installed libraries, which is clearly a problem.
*** Bug 95336 has been marked as a duplicate of this bug. ***
*** Bug 96624 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > DoubleHP: I'm waiting for upstream on this, as the openldap binaries themselves > get bad linking. The bug has been closed upstream as they were not able to reproduce this on SUSE. Hmm... :/
*** Bug 96989 has been marked as a duplicate of this bug. ***
Just upgraded from openldap-2.1.x to 2.2.26-r2 with no problems. just follow the upgrade steps: * # revdep-rebuild --soname liblber.so.2 * # revdep-rebuild --soname libldap.so.2 * # revdep-rebuild --soname libldap_r.so.2 backed up the database, and voila it's running great ;)
slight update on this. x29 openldap # readelf -d `which ldapsearch` Dynamic section at offset 0xa808 contains 26 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libldap-2.2.so.7] 0x00000001 (NEEDED) Shared library: [liblber-2.2.so.7] 0x00000001 (NEEDED) Shared library: [libssl.so.0.9.7] 0x00000001 (NEEDED) Shared library: [libcrypto.so.0.9.7] 0x00000001 (NEEDED) Shared library: [libcrypt.so.1] 0x00000001 (NEEDED) Shared library: [libresolv.so.2] 0x00000001 (NEEDED) Shared library: [libc.so.6] ... x29 openldap # readelf -d /usr/lib/libldap-2.2.so.7 Dynamic section at offset 0x39224 contains 25 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [liblber.so.2] 0x00000001 (NEEDED) Shared library: [libresolv.so.2] 0x00000001 (NEEDED) Shared library: [libssl.so.0.9.7] 0x00000001 (NEEDED) Shared library: [libcrypto.so.0.9.7] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x0000000e (SONAME) Library soname: [libldap-2.2.so.7] ...
from the build process (blank lines added for readability): /bin/sh /var/tmp/portage/openldap-2.2.27/work/openldap-2.2.27/libtool -- mode=link cc -O3 -march=athlon-xp -ggdb3 -pipe -release 2.2 -version-info 7:20:0 -rpath /usr/lib -o libldap.la bind.lo open.lo result.lo error.lo compare.lo search.lo controls.lo messages.lo references.lo extended.lo cyrus.lo modify.lo add.lo modrdn.lo delete.lo abandon.lo sasl.lo sbind.lo kbind.lo unbind.lo cancel.lo filter.lo free.lo sort.lo passwd.lo whoami.lo getdn.lo getentry.lo getattr.lo getvalues.lo addentry.lo request.lo os-ip.lo url.lo sortctrl.lo vlvctrl.lo init.lo options.lo print.lo string.lo util-int.lo schema.lo charray.lo tls.lo os-local.lo dnssrv.lo utf-8.lo utf-8-conv.lo version.lo ../../libraries/liblber/liblber.la -lresolv -lssl -lcrypto rm -fr .libs/libldap.la .libs/libldap.* .libs/libldap-2.2.* cc -shared bind.lo open.lo result.lo error.lo compare.lo search.lo controls.lo messages.lo references.lo extended.lo cyrus.lo modify.lo add.lo modrdn.lo delete.lo abandon.lo sasl.lo sbind.lo kbind.lo unbind.lo cancel.lo filter.lo free.lo sort.lo passwd.lo whoami.lo getdn.lo getentry.lo getattr.lo getvalues.lo addentry.lo request.lo os-ip.lo url.lo sortctrl.lo vlvctrl.lo init.lo options.lo print.lo string.lo util-int.lo schema.lo charray.lo tls.lo os-local.lo dnssrv.lo utf-8.lo utf-8-conv.lo version.lo -Wl,--rpath - Wl,/var/tmp/portage/openldap-2.2.27/work/openldap- 2.2.27/libraries/liblber/.libs ../../libraries/liblber/.libs/liblber.so - lresolv -lssl -lcrypto -Wl,-soname -Wl,libldap-2.2.so.7 -o .libs/libldap- 2.2.so.7.0.20 (cd .libs && rm -f libldap-2.2.so.7 && ln -s libldap-2.2.so.7.0.20 libldap- 2.2.so.7) (cd .libs && rm -f libldap.so && ln -s libldap-2.2.so.7.0.20 libldap.so)
yay, found the solution now. it was the ancient libtool that upstream used... this is fixed in the 2.2.27 ebuild, entering the tree shortly. (however revdep-rebuild is still required for anybody upgrading).
*** Bug 104136 has been marked as a duplicate of this bug. ***
*** Bug 105163 has been marked as a duplicate of this bug. ***
should the ebuild of openssh not automatically force a rebuild of openldap (at least once, if it were to fail)? I had an up-to-date tree, and just ran into the openssh / pam bug myself today. regards, /iaw
No, that would be a very bad idea indeed. Besides violating the principle of least astonishment, there's no telling what other things may break on users' systems if a package like OpenLDAP, against which a *lot* of things link, would get forcibly rebuilt.
