Bug#1122107: dpkg-shlibdeps: please consider symbol versions from '.gnu.version_r' section

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