As long as glibc-2.15-r3 is installed nss_ldap-265-r1 merges and functions OK. Upgrading to glibc-2.16.0 doesn't immediately break it but remerging nss_ldap-265-r1 afterwards does. Emerging nss_ldap-265-r1 on newer stage3 (after october 10th ?) always results in a broken nss_ldap. I tried both 20131205 and 20131212. Trying to login gives: "traps: login[1787] general protection ip:7f40e100f828 sp:6cc0cd81b980c468 error:0 in ld-2.16.so[7f40e0ff8000+22000]" with the sp: number differing. su gives: "su: symbol lookup error: /lib64/libnss_ldap.so.2: undefined symbol: __libc_lock_lock". Reproducible: Always
Created attachment 365334 [details] An unbroken emerge log
Created attachment 365336 [details] a broken emerge log
See also Forum thread http://forums.gentoo.org/viewtopic-t-978486.html
copying libnss_ldap-2.15.so (85128 bytes) from a working installation to libnss_ldap-2.16.so (85160 bytes) on a broken system seems to fix the problem
I confirm this bug. I waited with a major upgrade until KDE 4.11.2 got stabilised, did "emerge -e world" twice and ended up with a broken system, exactly in the manner described here.
It seems that nss_ldap-265-r2 solves the issue.
If so please confirm. My systems are now working, so I don't like to try. Could then maintenance on merging may be add a glibc check, so you get the right one?
Ok that seems to work. I'll add it to the forum thread
* Please do not file a Gentoo bug and instead report the above QA * issues directly to the upstream developers of this software. * Homepage: http://www.padl.com/OSS/nss_ldap.html