Is your GDM linked with pthreads ? Does is still deadlock if you run configure with --disable-pthread-support. I can see it happning if libc decided it needed to initizate the internal mutexes because libkrb5.so loaded the pthread library. That operation in not really garanteed to work. Love "Douglas E. Engert" <email@example.com> writes: > Love Hörnquist Åstrand wrote: >> I added com_err to krb5-config. >> Can you find out why the strlcpy isn't linked to the library as >> _com_err_strlcpy using roken_rename.h (config.h pulls it in). >> > OK, with the addition of the -lcom_err to the krb5_config > the change to com_err is not needed. The pam configures and > loads. Sorry about the confusion. > > > > But with the 20050502 version the kinit works, but the GDM > is hanging up in a mutux: > > #0 0x00b437a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0x00eb222e in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 > #2 0x00eaee3f in _L_mutex_lock_32 () from /lib/tls/libpthread.so.0 > #3 0x00676800 in __malloc_initialize_hook () from /lib/tls/libc.so.6 > #4 0x089fded0 in ?? () > #5 0x00674ff4 in ?? () from /lib/tls/libc.so.6 > #6 0xbffd5660 in ?? () > #7 0xbffd78b0 in ?? () > #8 0xbffd5618 in ?? () > #9 0x0062354e in pthread_mutex_lock () from /lib/tls/libc.so.6 > #10 0x0062354e in pthread_mutex_lock () from /lib/tls/libc.so.6 > #11 0x007dfa75 in krb5_clear_error_string () from /krb5h/lib/pam_krb5.so > #12 0x007e6913 in init_cred_loop () from /krb5h/lib/pam_krb5.so > #13 0x007e6dc4 in krb5_get_init_creds () from /krb5h/lib/pam_krb5.so > #14 0x007e70c9 in krb5_get_init_creds_password () from /krb5h/lib/pam_krb5.so > #15 0x007d10b9 in pam_sm_authenticate (pamh=0x89df8a8, flags=0, argc=5, > argv=0x89d8048) at ../src/pam_krb5afs.c:2104 > #16 0x00e0da47 in _pam_dispatch () from /lib/libpam.so.0 > #17 0x006ed69c in ?? () from /lib/security/pam_stack.so > #18 0x089df8a8 in ?? () > > > This was after the hash was sent to the card, and the signature returned. > Any ideas why this would happen?