> When this is printed, this means /sbin/ldconfig surely had to be run > successfully. Actually, I found out what's going on. If you are unlucky and /sbin/ldconfig run in glibc_post_upgrade (from glibc's %post) is the last /sbin/ldconfig run during the update, then at the point when that /sbin/ldconfig is run, files from both new glibc and old glibc might still exist in the filesystem. Particularly there might be still /lib/tls/librtkaio-2.3.3.so (from glibc-2.3.3-20 or earlier) and /lib/tls/librt-2.3.3.so (from glibc-2.3.3-24 (well, -21 or later, the rpm currently being installed)). The libraries have the same SONAME (that's because they provide the same ABI, librt.so.1) but different filename (librtkaio uses kernel aio, librt is pure userland implementation). Unfortunately librtkaio is the one picked by ldconfig, so librt.so.1 stays pointing to librtkaio-2.3.3.so. Some time after glibc %post ends rpm removes /lib/tls/librtkaio-2.3.3.so (as it is present just in the old package) and there is a stale symlink. If you are lucky and some other package's %post runs ldconfig after the librtkaio-2.3.3.so file is removed (or if you are upgrading already from glibc which did not have that file), everything is fine. Guess I'll need to add some more ugly hacks into glibc_post_upgrade :(. FYI, librtkaio has been removed for FC2, because 2.6.x kernel AIO support is in a bad shape and insufficient for POSIX AIO on top of it. Jakub
