Package: dpkg-dev Version: 1.22.21 Severity: wishlist Control: block 1122038 by -1
Hi, 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. Thanks Aurelien
