As stated in the summary, I did few research on this matter. There's an entry in the OpenLDAP ITS (<http://www.openldap.org/its/index.cgi/Incoming?id=6880;page=9>) where it says : > Your trace shows that both libldap and libldap_r are present. Your PHP is built > incorrectly. You cannot link both libraries into the same program; they are not > compatible. Closing this ITS. On my server, I typed : zsh 1007 % ldd /usr/libexec/dovecot/auth | grep ldap libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00007fc77ebc9000) libldap_r-2.4.so.2 => /usr/lib64/libldap_r-2.4.so.2 (0x00007fc77d233000) It seems that /usr/libexec/dovecot/auth is linked against both libldap-2.4.so.2 and libldap_r-2.4.so.2 which wont work as excpeted. Reproducible: Always zsh 1008 % emerge -p net-mail/dovecot These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] net-mail/dovecot-2.0.16-r1 USE="bzip2 caps doc ipv6 ldap maildir managesieve pam postgres sieve sqlite ssl zlib -cydir -kerberos -mbox -mdbox -mysql -sdbox -static-libs -suid -vpopmail" 0 kB
Created attachment 297543 [details] emerge --info
See 'lddtree /usr/libexec/dovecot/auth' instead.
Please give 'lddtree /usr/libexec/dovecot/auth' output. What is your version of openldap?
zsh 1074 % lddtree /usr/libexec/dovecot/auth auth => /usr/libexec/dovecot/auth (interpreter => /lib64/ld-linux-x86-64.so.2) libdovecot.so.0 => /usr/lib64/dovecot/libdovecot.so.0 librt.so.1 => /lib64/librt.so.1 libpthread.so.0 => /lib64/libpthread.so.0 libcrypt.so.1 => /lib64/libcrypt.so.1 libpam.so.0 => /lib64/libpam.so.0 libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 libresolv.so.2 => /lib64/libresolv.so.2 libgnutls.so.26 => /usr/lib64/libgnutls.so.26 libtasn1.so.3 => /usr/lib64/libtasn1.so.3 libz.so.1 => /lib64/libz.so.1 libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 libpq.so.5 => /usr/lib64/libpq.so.5 libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 libldap_r-2.4.so.2 => /usr/lib64/libldap_r-2.4.so.2 libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 libicui18n.so.48 => /usr/lib64/libicui18n.so.48 libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/32/libstdc++.so.6 ld-linux.so.2 => /lib64/ld-linux.so.2 libm.so.6 => /lib64/libm.so.6 libgcc_s.so.1 => /lib64/libgcc_s.so.1 libicuuc.so.48 => /usr/lib64/libicuuc.so.48 libicudata.so.48 => /usr/lib64/libicudata.so.48 libdl.so.2 => /lib64/libdl.so.2 libc.so.6 => /lib64/libc.so.6 net-nds/openldap-2.4.25-r1 USE="berkdb crypt gnutls icu ipv6 overlays ssl syslog tcpd -cxx -debug -experimental -iodbc -kerberos -minimal -odbc -perl -samba -sasl (-selinux) -slp -smbkrb5passwd"
dovecot only links against libldap-2.4.so.2. Please get a backtrace. http://www.gentoo.org/proj/en/qa/backtraces.xml should help.
Here's a backtrace, maybe you want more information ? Reading symbols from /usr/libexec/dovecot/auth...Reading symbols from /usr/lib64/debug/usr/libexec/dovecot/auth.debug...done. done. [New LWP 14189] warning: Can't read pathname for load map: Erreur d'entr�e/sortie. [Thread debugging using libthread_db enabled] Core was generated by `dovecot/auth -w'. Program terminated with signal 11, Segmentation fault. #0 0x00007f66b787cd03 in ldap_free_urllist () from /usr/lib64/libldap-2.4.so.2 (gdb) bt full #0 0x00007f66b787cd03 in ldap_free_urllist () from /usr/lib64/libldap-2.4.so.2 No symbol table info available. #1 0x00007f66b5ce537b in ?? () from /usr/lib64/libldap_r-2.4.so.2 No symbol table info available. #2 0x00007f66b5cca62f in ?? () from /usr/lib64/libldap_r-2.4.so.2 No symbol table info available. #3 0x0000000000000022 in ?? () No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available.
I've rebuilt dovecot with USE="-postgresql", getting rid of the indirect linkage to /usr/lib64/libldap_r-2.4.so.2 and I don't get anymore this segfault message in my log and dmesg.
+ 09 Jan 2012; Eray Aslan <eras@gentoo.org> dovecot-1.2.17.ebuild, + dovecot-2.0.15.ebuild, dovecot-2.0.16.ebuild, dovecot-2.0.16-r1.ebuild, + dovecot-2.0.17.ebuild, dovecot-2.1_rc3.ebuild: + block against postgresql-base[ldap,threads] - bug #396691 +
This solution seems kind of rash, but perhaps fine as a temporary measure. (1) add a USE=threads to openldap that causes libldap* be a symlink to the corresponding libldap_r*. postgres[threads] can then depend on openldap[threads]. The same goes for anything else that links with libldap_r. (2) finagle dovecot to try for libldap_r if USE=openldap I don't understand why people are scared of threads. They have been around for four or so decades, and processors don't get faster anymore.
Before the list, I intended to say 'these are two more ideal solutions' or something...
Created attachment 298905 [details, diff] openldap-2.4.24.ebuild.patch 1) Make symlinks libldap* -> libldap_r* for shared/static libraries. 2) s/libldap_r/libldap/ < libldap_r.la > libldap.la It applies cleanly to the other ebuilds; I just did 2.4.24 because it was amd64-stable. Then: --- /usr/portage/dev-db/postgresql-base/postgresql-base-9.1.1.ebuild 2011-12-17 10:31:06.000000000 -0800 +++ /usr/local/portage/dev-db/postgresql-base/postgresql-base-9.1.1.ebuild 2012-01-13 21:28:06.314215452 -0800 @@ -46,7 +46,7 @@ >=app-admin/eselect-postgresql-1.0.10 virtual/libintl kerberos? ( virtual/krb5 ) - ldap? ( net-nds/openldap ) + ldap? ( net-nds/openldap threads? ( net-nds/openldap[threads] ) ) pam? ( virtual/pam ) readline? ( sys-libs/readline ) ssl? ( >=dev-libs/openssl-0.9.6-r1 ) Finally, I reverted the openldap ebuilds.
Please open a separate bug for it. Thank you.
Can I ask to remove that fix, since for now it undeservedly blocks new postgres[ldap,threads] to coexist with new dovecot? :)
