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

Guillem Jover guillem at debian.org
Tue Sep 16 22:46:25 BST 2025


Control: reassign -1 libgctp
Control: tag -1 patch
Control: retitle -1 libgctp: Fix SONAME filename handling

On Tue, 2025-09-16 at 16:57:25 +0200, Michael Biebl wrote:
> Am 16.09.25 um 16:28 schrieb Guillem Jover:
> > On Tue, 2025-09-16 at 15:49:22 +0200, Michael Biebl wrote:
> > > Package: dpkg-dev
> > > Version: 1.22.21
> > > Severity: important
> > > File: /usr/bin/dpkg-shlibdeps
> > 
> > > for some back story please see
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111805#49
> > > 
> > > In https://salsa.debian.org/glibc-team/glibc/-/commit/5e3aa111654e9aad080881fb98f9e5b01b277857
> > > (currently only available via Debian experimental),
> > > the duplicated paths for /lib were removed from ld.so.conf files.
> > > 
> > > This triggered a build failure for ncl, hdf-eos5 and ruby-hdfeos5.
> > > 
> > > All those packages link against libgctp and the build failures look
> > > similar:
> > 
> > > If you want to reproduce the problem, remove the line
> > > /lib/x86_64-linux-gnu
> > > in /etc/ld.so.conf.d/x86_64-linux-gnu.conf and try to build one of those
> > > packages in debian sid or trixie.
> > 
> > The problem can be reproduced in Debian sid, with no ld.so.conf
> > modifications. (Or I botched my testing?)
> 
> I can't repoduce the failure with with no ld.so.conf modifications.

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,
Guillem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-SONAME-filename-handling.patch
Type: text/x-diff
Size: 3842 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20250916/f09d5d10/attachment.patch>


More information about the debian-science-maintainers mailing list