This morning libdv was upgraded, and this broke mplayer. Therefore I ran revdep-rebuild to scan for other broken packages, but found that it totally missed the broken mplayer binary. A lot of trial and error showed that when /opt/vmware/lib/lib was in the LD_LIBRARY_PATH before /usr/lib, then ldd would try to get libgtk-1.2.so.0 from vmware instead. However, since /opt/vmware/lib/lib/libgtk-1.2.so.0 is actually a directory, ldd fails completely with this message (which is redirected to /dev/null): /usr/bin/mplayer: error while loading shared libraries: /opt/vmware/lib/lib/libgtk-1.2.so.0: cannot read file data: Error 21 The fact that the libdv link is also broken is not registered. So, it seems to me that a lot of broken dependencies could go unnoticed for quite some time if you have vmware installed. Not sure how it should be solved, though.
The updated revdep-rebuild script in bug #62644 should handle this situation the majority of the time. It ensures that the standard library locations are listed first in the LD_LIBRARY_PATH.
*** Bug 80695 has been marked as a duplicate of this bug. ***
*** Bug 80557 has been marked as a duplicate of this bug. ***
*** Bug 81810 has been marked as a duplicate of this bug. ***
Instead of marking similar bugs as closed - start providing a good fix the distriubtes fast via portage, so that a) systems get fixed soon b) systems stop getting broken c) bug reports stoping poping up I did a search on the forums and on the bug database AND DID NOT find any solution, why libdv.so.2 seems to be missing on my system. I also noticed it by an error message of mplayer. After revdep-rebuild I noticed that several applications are broken. Since I', doing nearly daily: "emerge --sync ; emerge --newuse -vD world" my system is supposed to be up2date. And I DO NOT have vmware installed on my system - so this can't be it.
BTW, the reason you get the Error 21 from ldd is because of a bug in glibc's dynamic loader. see bug #89381.
See also bug #58346, I posted a patch it works for me.
*** Bug 96486 has been marked as a duplicate of this bug. ***
*** Bug 58346 has been marked as a duplicate of this bug. ***
*** Bug 100207 has been marked as a duplicate of this bug. ***
Revdep-rebuild finds after new dbus installation: ######################################## Checking dynamic linking consistency... broken /usr/kde/3.5/lib/kde3/kded_mediamanager.so (requires libdbus-1.so.1) broken /usr/lib/libk3bdevice.so.2.0.1 (requires libdbus-1.so.1) done. (/root/.revdep-rebuild.3_rebuild) Assigning files to ebuilds... done. (/root/.revdep-rebuild.4_ebuilds) Evaluating package order... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild... emerge --oneshot =app-cdr/k3b-0.12.10 ################### where "equery b kded_mediamanager.so" points out also kdebase-kioslaves. After reemerging kdebase-kioslaves "broken /usr/kde/3.5/lib/kde3/kded_mediamanager.so (requires libdbus-1.so.1)" dissapears from the revdep-rebuild list.
and shouldn't? that's what it has to do!
revdep should find kdebase-kioslaves as broken package for re-emerge
in bug #96946 comment #38 , it is said that this bug is fixed. Please check and close.
*** This bug has been marked as a duplicate of bug 96946 ***
Not the same bug as #96946 and it is not fixed.
This should be fixed when we convert to scanelf to check for breakage in the python rewrite of revdep-rebuild being developed for gentoolkit-0.3.1
