Hi Guillem, On 2025-12-08 01:45, Guillem Jover wrote: > Hi! > > On Sun, 2025-12-07 at 12:04:40 +0100, Aurelien Jarno wrote: > > Package: dpkg-dev > > Version: 1.22.21 > > Severity: wishlist > > Control: block 1122038 by -1 > > > 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, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net
