Bug#1115395: dpkg-shlibdeps fails to find libraries if /lib is removed from ld.so.conf search path

[Michael Biebl]

Hi Guillem

Am 16.09.25 um 23:46 schrieb Guillem Jover:

> This can be reproduced on a system with a merged-/usr with selective
> filename aliasing (instead of global directory aliasing).
> 
> The problem is that merged-/usr with directory aliasing has been
> shadowing this problem, which is a packaging issue in libgctp. The
> non-dev package should be containing the shared library named as its
> SONAME, which is what dpkg-shlibdeps expects, to be able to map from
> the SONAME to the package that contains the shlibs file.
> 
> This has worked on merged-/usr systems with directory aliasing (and
> /lib in the ld.so default path) because dpkg-shlibdeps was able to
> find the file on the filesystem but no match on its db, which
> resulted in triggering a fallback to canonicalize the filename and
> overwrite the filename to package mapping which then leads it to the
> package containing the shlibs file (libgctp-2.0.0 vs libgctp-dev).
> 
> On systems where there is no searching or presence of SONAME via /lib,
> then dpkg-shlibdeps does not trigger the canonicalization and instead
> finds the mapping to the -dev package, which contains no shlibs file,
> and that fails the build.
> 
> The attached patch should fix the issue (at least it does for me).
> Reassigning to libgctp.

Thanks a lot for the detailed explanation (and the patch)!


Looping in Aurelien as well so he is aware that there is now a fix for 
this issue and should not block this glibc change being uploaded to 
unstable.

Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20250916/cb879161/attachment-0003.sig>