libnotify.so.1 => /usr/lib/libnotify.so.1 libpng14.so.14 => /usr/lib/libpng14.so.14 ... libpng12.so.0 => /usr/lib32/libpng12.so.0

With the latest libpng bump (1.2 -> 1.4) there was a change in the libname. Most apps were easily rebuilt, but a few naughty ones were really fighting it. The usual symptoms were "random" failures while running revdep-rebuild. For some people lafilefixer did it, for others the rebuild of cairo or pango seemed to do the trick.What bothered me was that these packages were consistently hiding from revdep-rebuild and somehow convincing it that they were fine ... and on my notebook I managed to hit this exact issue.I haven't tried to reproduce it to see how this goes wrong, but here's some of the output of lddtree on /usr/bin/nm-applet where I noticed the failure:Obviously this is pretty fu.... funny. There's a mix of both versions involved because at that time not all libs had been rebuilt. But ... here's the thing that tripped me. How the BLEEP does it manage to confuse the paths so badly that a 64bit lib tries to integrate 32bit libs?This makes ldd assume that the dependency is satisfied while linking will fail. Can't work. It's wrong. And because it appears to not be missing a lib it's a real pain to figure out.Maybe this is enough of a hint to permanently fix the problem - the next .so bump could explode in the same way, and that's something we really don't want to happen. I don't know how this sneaks in, so any debugging to track it down is appreciated.