Am 27.11.2011 01:59, schrieb Paul Hartman:
> On Sat, Nov 26, 2011 at 6:25 PM, Adam Carter <adamcarter3@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