Hi! On Mon, 2025-12-08 at 18:53:56 +0100, Aurelien Jarno wrote: > On 2025-12-08 01:45, Guillem Jover wrote: > > On Sun, 2025-12-07 at 12:04:40 +0100, Aurelien Jarno wrote: > > > When symbol versioning is in use, the '.gnu.version_r' section records > > > all symbol version requirements declared by the binary for each of its > > > shared library dependencies. At runtime, ld.so checks that all symbol > > > versions are provided by the target library and refuse to run if a > > > required symbol version is missing. > > > > > > On its side, dpkg-shlibdeps computes versioned dependencies only from > > > the versions used by the symbols (from the '.dynsym' section). This > > > works fine as long as every symbol version required by the binary is > > > also reference by at least one symbol. > > > > > > Unfortunately, recent binutils and glibc versions started to use the > > > symbol version requirements from section '.gnu.version_r' as ABI flags, > > > meaning they do not have symbols associated with them. For instance the > > > 'GLIBC_ABI_GNU_TLS' symbol on i386, which triggered the issue in bug > > > #1122038. It is not seen by dpkg-shlibdeps, causing the generated > > > dependency on libc6 to be lower than what is actually need at runtime, > > > and the binary fails to start with older glibc. > > > > > > Would it be possible for dpkg-shlibdeps to handle the requirements found > > > in the '.gnu.version_r' section? In the above case it means that an > > > entry for GLIBC_ABI_GNU_TLS in the '.gnu.version_r' section would match > > > the ' GLIBC_ABI_GNU_TLS@GLIBC_ABI_GNU_TLS 2.42' in the symbols file. > > > > Ah, hmm, that's unfortunate. The attached patch seems to fix this for > > me (once I removed the workaround from the libc6:i386.symbols file > > from the chroot. I've queued the patch for my next push, which will be > > part of the 1.23.0 release. > > > > Thanks a lot for the quick fix, I confirm that it works as expected.
Thanks for checking! I was wondering, given the discussion in the glibc bug which was unclear to me, whether the fix in dpkg should be backported to the version in Debian trixie as well? If so I'd mark the commit as a stable-candidate, and then queue it for the next stable update, but that would need to wait for the dpkg upload to first hit unstable/testing, which is currently blocked by a debhelper upload. Thanks, Guillem
