I rewrote lddd from extra/devtools. The intent was to make it faster and remove false positives, as well as support for ignoring certain files completely, filtering the list of missing libs to handle optional dependencies, take /etc/ld.so.conf into account and in general make it more usable. NB: uses bash-4 features. URL: http://ino-waiting.gmxhome.de/files/lddd-c.sh Here's the help screen: $ lddd-c.sh -h Use lddd-c.sh [options] [paths] Default-paths: $PATH, /lib:/usr/lib:/opt/qt/lib:/opt/kde/lib:/usr/lib/libfakeroot:/opt/NX/lib:/usr/local/lib:/usr/local/libexec options: -d <item>: do not check glob <item>, can be given multiple times. -l <item>: ignore missing library glob <item>, multiple times. -L: do not use LD_LIBRARY_PATH running ldd(1)[1]. -v: be more and more chatty. -D <glob>: trigger tracing on meeting <glob>, debugging aid. Environment variables: $LDDD_LIB_IGNORE: globs of missing lib-names to ignore[2]. $LDDD_DONT_CHECK: globs of file names to completely ignore[2]. [1] risks false positives, but finds all broken ELF dependencies. [2] space separated list of globs, needs to be quoted to the shell. NB: A broken ELF file will be reported unless it is ignored ('-d' option or $LDDD_DONT_CHECK) or _ALL_ of its missing libs are ignored ('-l' or $LDDD_LIB_IGNORE)! _version: 20090727-2016_ The "new and improved" algorithm goes like this: 1. All files executable by the user or matching the customary *.so patterns are collected after verifying their ELFness. 2. The file paths are checked to see if their base directories contain any libraries and these directories are collected into LD_LIBRARY_PATH. 3. In a third loop, the files from step one are checked by ldd(1) prefixed with this LD_LIBRARY_PATH to see if any prerequisites are missing. This step is repeated without the path to check the odd customer. 4. Suspects aquired this way are sent to a co-process to determine the packages they belong to. 5. Results are collected into files in /tmp/lddd-c.sh-$UID and a summary listed to stdout. This makes it easy to use in cron-jobs. Detail is controlled by the number of '-v' options. Step four was intended to speed up the process, but as it turns out it doesn't help all that much. The pacman call is indeed expensive and can be done in parallel, but it obviously competes for disk access. Therefore the co-process caches the file list of any broken package expecting to find more broken files in it, but this only helps big packages with several broken executables. All in all lddd-c.sh is an improvement over the simpler lddd and the terribly hacked findbrokenpkgs[1]. As there should be no false positives, it should report b0rked packages after botched or incomplete updates in a reliable way. Valuable testing was done by Allan McRae and AttilaH. Some nasty bugs would still stink the code without their patience. [1] http://bbs.archlinux.org/viewtopic.php?id=13882 clemens