> objdump isn't a solution either, while it sometimes can read the other > shared library, it doesn't provide the linker search patch which is of > critical importance to get this stuff right. Hmm... But what for is that search path? As far as I understand, dpkg-shlibdeps should just get NEEDED sonames, and match those against available shlibs files. And that is what code actually does. Path information is used only if something is not found in this way - that means, package that provides the library does not provide shlibs data, which is a bug anyway. So looks it is safe to remove any path processing from dpkg-slibdeps, and use only objdump. If something breaks, it should be fixed elsewhere (i.e. proper shlibs data added to packages). But anyway, this is not enough: 32bit and 64bit versions of a library are likely to have same sonames, so they can't be distinguished within the current shlibs file format. Complete fix should probably add one more field to shlibs files - the binary format. So a possible way to fix this is: - add binary format field to slibs file format [for backward-compatability, the field should be optional and default to 'normal' binary format for the architecture; packages providing such extended shlibs data should conflict with dpkg-dev versions that don't support it] - fix dpkg-shlibdeps: don't call ldd; use objdump both to extract NEEDED and to get binary format; add extended shlibs format handling; - fix any packages that happen to depend on [just removed] dpkg-shlibdeps support of no shlibs information.
Description: PGP signature