Samuel Thibault <[EMAIL PROTECTED]> writes:
> retitle 285857 dpkg-shlibdeps should better match ldd and dpkg --search
> results
> thanks
>
> Le jeu 16 d�c 2004 � 15:47:08 +0100, Goswin von Brederlow a tapot� sur son
> clavier :
>> > No, because unless you add /mnt/space/usr to LD_LIBRARY_PATH, ldd will
>> > correctly find used librairies in /usr/lib (and this matches dpkg's
>> > idea), there's no possible confusion here.
>>
>> That sounds right but on amd64 we did have problems with the lib64
>> link, libraries showing up as /usr/lib/libfoobar.so instead of
>> /usr/lib64/libfoobar.so as dpkg thought. All I'm saying is that I've
>> seen this problem before and not in the hurd way. Canonify is the more
>> general solution.
>
> Ok.
>
> Another solution would be (when ldd returns /lib/libbar.so.1.0),
> instead of calling dpkg --search /lib/libbar.so.1.0, to
> call dpkg --search libbar.so.1.0, which will return
>
> libbar: /usr/lib/libbar.so.1.0
>
> and then check that /lib/libbar.so.1.0 and /usr/lib/libbar.so.1.0
> really are the same file: same device, same inode.
>
> It is possible that dpkg --search returns several results: dpkg --search
> libm-2.3.2.so for instance (tls and non-tls versions). A loop would
> check out which one corresponds to ldd's result.
>
> Regards,
> Samuel
Exactly my thoughts.
MfG
Goswin
