Am 27.11.2011 01:59, schrieb Paul Hartman: > On Sat, Nov 26, 2011 at 6:25 PM, Adam Carter <adamcart...@gmail.com> wrote: >>>>>>> /lib64/libc.so.6: version `GLIBC_2.14' not found (required by >>>>>>> /lib64/libcrypt.so.1) >>>>>>> >>>>>>> There were no @preserved-rebuild and revdep-rebuild found nothing. I >>>>>>> rebuilt pam and things seem to be working again. Are there any other >>>>>>> packages I should rebuild before encountering a problem? Or some way >>>>>>> to detect which need to be rebuilt? Should I re-emerge world against >>>>>>> my new glibc? :) >> >> How did you know to rebuild pam? >> >> Both /lib64/libc.so.6 and /lib64/libcrypt.so.1 are from glibc, and I >> interpret your error as 'libcrypt.so.1 couldn't find a GLIBC_2.14 >> version of /lib64/libc.so.6', which doesn't make any sense to me as >> both files are from the same package. How could the version dependency >> between them be incorrect? > > Sorry, I accidentally pasted the incomplete error message. It was part > of this kind of message in my syslog: > > Nov 25 19:40:01 [cron] PAM unable to > dlopen(/lib64/security/pam_unix.so): /lib64/libc.so.6: version > `GLIBC_2.14' not found (required by /lib64/security/pam_unix.so) > Nov 25 19:40:01 [cron] PAM adding faulty module: /lib64/security/pam_unix.so >
THAT is the reason why neither revdep-rebuild nor @preserved-rebuild found pam. It dynamically loads libraries using dlopen instead of letting the dynamic linker handle it when the application is started. There is no reasonable way for revdep-rebuild to find these issues. Regards, Florian Philipp
signature.asc
Description: OpenPGP digital signature
