This is a feature request. I wasn't happy with the resolution of bug 396691. The problem was that postgresql-base[ldap,threads] used libldap_r while dovecot used libldap and depended on postgresql-base, so both get linked in. They have the same interface and are incompatible. I think a better solution is to embrace threads, since we cannot move forward with computers without exploiting multiple CPUs. I propose that 'threads' be added as a USE flag to openldap. Its behavior will be to make libldap.so, libldap.a, etc. links to libldap_r.so, libldap_r.a, etc. (Making the symlink for the static library isn't necessary, but it's what I would want if I had USE=threads. Then anything that depends on libldap_r can depend on openldap[threads]. No more issues of having incompatible libraries that potentially only cause a bug in rare race conditions. I have patches for the openldap & postgresql-base ebuilds. Only other packages using libldap_r: app-emulation/wine[threads] net-print/cups[threads] So it should be easy! Reproducible: Always
Created attachment 298937 [details, diff] openldap-2.4.24.ebuild.patch (I chose 2.4.24 since it's the latest amd64-stable release AKA what I had installed. It applies cleanly on the newer ebuilds, though.) I'm not really sure if I put it in the right IUSE_* section. Anyway, it does two things in src_install(): (1) Replace libldap-*so*, libldap.so, libldap.a with a symlink to the corresponding libldap_r version. (2) sed 's/libldap_r/libldap/g' < libldap_r.la > libldap.la The patch for postgresql-base is much shorter, so I'll include it inline: --- /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 ) It should be almost the same for wine and cups. One more thing, if/when you edit the openldap ebuilds, please do a 's/ \t/\t/' on it. It is super-bothersome.
Oh one more thing, apparently app-emulation/emul-linux-x86-baselibs also contains libldap and libldap_r. I'm not sure if anybody cares. The openldap ebuild patch could just be used with little effort.
No. The consumers should move to libldap_r themselves. OpenLDAP should NOT force all libldap consumers to libldap_r.
Except that if you want threaded software, you want to use libldap_r. Suppose you also want to use libwhatever and libwhatever uses libldap. I guess I should get started porting every single thing that uses libldap to libldap_r even if it doesn't care ... oh wait that's what this patch does.
(In reply to comment #4) > Except that if you want threaded software, you want to use libldap_r. Suppose > you also want to use libwhatever and libwhatever uses libldap. libwhatever should be changed to link against libldap_r. > I guess I should get started porting every single thing that uses libldap to > libldap_r even if it doesn't care ... oh wait that's what this patch does. If you want to go that route, convert your patch to autoconf/automake changes, and convince upstream to take it.
And while upstream's at it, add pkgconfig support, which would make this much easier.
