It appears that functions __libc_lock_lock and similar were removed in glibc-2.16. I cannot find them anywhere in the glibc headers, which causes implicit-declaration and hence runtime linking problems: ldap-nss.c:586:3: warning: implicit declaration of function '__libc_lock_lock' [-Wimplicit-function-declaration] ldap-nss.c:632:3: warning: implicit declaration of function '__libc_lock_unlock' [-Wimplicit-function-declaration] ldap-nss.c:1254:3: warning: implicit declaration of function '__libc_once' [-Wimplicit-function-declaration] util.c:97:3: warning: implicit declaration of function '__libc_lock_lock' [-Wimplicit-function-declaration] util.c:104:4: warning: implicit declaration of function '__libc_lock_unlock' [-Wimplicit-function-declaration] /bin/login: symbol lookup error: /lib64/libnss_ldap.so.2: undefined symbol: __libc_lock_lock Reproducible: Always Portage 2.2.0_alpha138 (!../../var/cache/portage/gentoo/profiles/default/linux/powerpc/ppc64/10.0/64bit-userland, gcc-4.6.3, glibc-2.16.0, 2.6.18-308.16.1.el5 x86_64) ================================================================= System uname: Linux-2.6.18-308.16.1.el5-x86_64-Quad-Core_AMD_Opteron-tm-_Processor_2352-with-gentoo-2.1 Timestamp of tree: Tue, 16 Oct 2012 21:45:01 +0000 distcc 3.1 x86_64-pc-linux-gnu [disabled] app-shells/bash: 4.2_p37 dev-lang/python: 2.7.3-r2, 3.2.3::ambro-cross sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.9.8.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.68 sys-devel/automake: 1.11.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.7.2 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.4-r2 (virtual/os-headers) sys-libs/glibc: 2.15-r2 Repositories: gentoo ambro-cross local sunrise ACCEPT_KEYWORDS="ppc64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-pipe -O2 -mcpu=cell -mabi=altivec" CHOST="powerpc64-unknown-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-pipe -O2 -mcpu=cell -mabi=altivec" DISTDIR="/var/cache/portage/distfiles" EMERGE_DEFAULT_OPTS="--usepkg --binpkg-respect-use --keep-going" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs buildpkg config-protect-if-modified distlocks ebuild-locks fixlafiles news parallel-fetch parallel-install preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-$ FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu" MAKEOPTS="-j3" PKGDIR="/mnt/ppc64/var/cache/portage/packages" PORTAGE_COMPRESS="xz" PORTAGE_CONFIGROOT="/mnt/ppc64/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp/cross-powerpc64-unknown-linux-gnu" PORTDIR="/var/cache/portage/gentoo" PORTDIR_OVERLAY="/var/lib/layman/ambro-cross /var/cache/portage/local /var/cache/portage/overlays/sunrise" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Created attachment 326768 [details, diff] nss_ldap-265-glibc-2.16.patch Attached patch fixes the issue for me and was submitted upstream [1]. [1] http://bugzilla.padl.com/show_bug.cgi?id=445
I also submitted an additional patch for better pthread detection in another upstream bug: http://bugzilla.padl.com/show_bug.cgi?id=446
Please consider this important, systems using nss_ldap that are upgraded to glibc 2.16 become unbootable without disabling ldap in nsswitch.conf
*ping!*
I have the same issue!
Same here. I've applied the patch from comment #1 and on the face of it, all seems well again.
Issue still present. The patch from comment #1 works for me as well. If you don't want to include the provided patch for some reason, maybe you can make nss_ldap at least use epatch_user, so custom patching is easier?
How to restore the system image when it is already broken by this bug?
Here's what I had to do: 1. boot with the livecd, and mount / somewhere (I just used /mnt) 2. back up /mnt/etc/nsswitch.conf 3. edit /mnt/etc/nsswitch.conf, remove 'ldap' from each of the active entries 4. sync && umount /mnt && reboot 5. assuming it boots safely, log in as root or a local user who can elevate to root priviledges (you won't be able to contact the LDAP server for this!) 6. copy <portage>/sys-auth/nss_ldap/nss_ldap-265-r1.ebuild to nss_ldap-265-r2.ebuild, and open the file in your text editor of choice 7. add a call to epatch_user in the src_prepare section, towards the end, right before the sed statement 8. copy the patch above to /etc/portage/patches/sys-auth/nss_ldap-265-r2 9. re-emerge sys-auth/nss_ldap, verifying that it picks the -r2 version 10. restore your backup of nsswitch.conf 11. reboot, and you should be OK.
while this fix appears to work for most things, in some instances nss_ldap is now crashing. here's a TB from thunderbird. Program received signal SIGSEGV, Segmentation fault. 0x00007ffff6e6aeb8 in strtok_r () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff6e6aeb8 in strtok_r () from /lib64/libc.so.6 #1 0x00007ffff68d2eae in ldap_str2charray () from /usr/lib64/thunderbird/libldap60.so #2 0x00007fffdedb2d05 in ?? () from /usr/lib64/libldap-2.4.so.2 #3 0x00007fffdedb4478 in ldap_int_initialize_global_options () from /usr/lib64/libldap-2.4.so.2 #4 0x00007fffdedb45da in ldap_int_initialize () from /usr/lib64/libldap-2.4.so.2 #5 0x00007fffded9a52a in ldap_create () from /usr/lib64/libldap-2.4.so.2 #6 0x00007fffded9aa21 in ldap_initialize () from /usr/lib64/libldap-2.4.so.2 #7 0x00007fffdefd9cee in ?? () from /lib64/libnss_ldap.so.2 #8 0x00007fffdefdb134 in ?? () from /lib64/libnss_ldap.so.2 #9 0x00007fffdefdc767 in ?? () from /lib64/libnss_ldap.so.2 #10 0x00007fffdefdce27 in _nss_ldap_getpwnam_r () from /lib64/libnss_ldap.so.2 #11 0x00007ffff6e9ddc5 in getpwnam_r () from /lib64/libc.so.6 #12 0x00007fffefa01c5e in ?? () from /usr/lib64/libglib-2.0.so.0 #13 0x00007fffefa026fd in g_get_user_name () from /usr/lib64/libglib-2.0.so.0 #14 0x00007fffe438e6ed in ?? () from /usr/lib64/libgnomeui-2.so.0 #15 0x00007fffefce403f in g_type_create_instance () from /usr/lib64/libgobject-2.0.so.0 #16 0x00007fffefcc8778 in ?? () from /usr/lib64/libgobject-2.0.so.0 #17 0x00007fffefcca219 in g_object_newv () from /usr/lib64/libgobject-2.0.so.0 #18 0x00007fffefcca88c in g_object_new () from /usr/lib64/libgobject-2.0.so.0 #19 0x00007fffe4390232 in gnome_client_new_without_connection () from /usr/lib64/libgnomeui-2.so.0 #20 0x00007fffe4390eb0 in ?? () from /usr/lib64/libgnomeui-2.so.0 #21 0x00007fffe3ca86ce in gnome_program_preinit () from /usr/lib64/libgnome-2.so.0 #22 0x00007fffe3ca934a in ?? () from /usr/lib64/libgnome-2.so.0 #23 0x00007fffe3ca958d in gnome_program_initv () from /usr/lib64/libgnome-2.so.0 #24 0x00007fffe3ca966b in gnome_program_init () from /usr/lib64/libgnome-2.so.0 #25 0x00007ffff3836734 in ?? () from /usr/lib64/thunderbird/libxul.so #26 0x00007ffff382f82f in ?? () from /usr/lib64/thunderbird/libxul.so #27 0x00007ffff3831709 in ?? () from /usr/lib64/thunderbird/libxul.so #28 0x00007ffff383195d in XRE_main () from /usr/lib64/thunderbird/libxul.so #29 0x0000000000402d10 in _start () i'll do some more debugging tonight
I think that might be the same as bug #463658.
I've had the same problem on glibc-2.17. Apologies for the maintainer being away for a while. We are going to take this patch.
Created attachment 351284 [details, diff] nss_ldap.patch patch for 1. http://bugzilla.padl.com/show_bug.cgi?id=445 and http://bugzilla.padl.com/show_bug.cgi?id=446 2. EAPI bump to 5 and installdir hack for Prefix Please review.
Created attachment 351286 [details, diff] nss_ldap.patch stripped Manifest diff
Just committed. Feel free to reopen this bug when necessary. 18 Jun 2013; Benda Xu <heroxbd@gentoo.org> +files/nss_ldap-265-installdir.patch, +files/nss_ldap-265-pthread.patch, +nss_ldap-265-r2.ebuild: fix __libc_lock_lock symbol against >=glibc-2.16 (bug 438692, thanks to Dennis Schridde). bump to EAPI 5 and add Prefix support.
This also fix a ldap access segment fault on nsswitch.conf when mit-krb5 replace with heimdal. nss_ldap-265-r2 fixed it. When can we see it unmask?
(In reply to Chan Min Wai from comment #16) > This also fix a ldap access segment fault on nsswitch.conf when mit-krb5 > replace with heimdal. > > nss_ldap-265-r2 fixed it. > > When can we see it unmask? Not sure what you means by unmask. Do you mean stablize it?
This seriously breaks all stable users using LDAP and is very not funny. Please stabilize sys-auth/nss_ldap-265-r2 on all involved arches.
This patch STILL shows ldap-nss.c:1923:4: warning implicit declaration of function 'gss_krb5_ccache_name' [-Wimplicit-function-declaration] so there are still missing bits. (mit-krb5 is used)
Stable for HPPA.
(In reply to Nico Baggus from comment #19) > This patch STILL shows > ldap-nss.c:1923:4: warning implicit declaration of function > 'gss_krb5_ccache_name' [-Wimplicit-function-declaration] > > so there are still missing bits. (mit-krb5 is used) That sounds like an independent bug, maybe open a new bugreport for it.
That might depend on point of view. if the error is about: nss_ldap giving errors about undeclared functions NO if the error is about: nss_ldap failing because of changes in glibc then YES. In both cases nss_ldap will fail. nss_ldap is often used together with kerberos so YMMV.
Stable for amd64 and x86
ia64 stable
ppc64 stable
ppc stable
sparc stable
Stable on alpha. Closing.
