Package: release.debian.org Severity: important User: release.debian....@packages.debian.org Usertags: binnmu
Hi! The objdump tool changed its output for copy relocations for versioned symbols (from @@ to @) in binutils 2.26 (uploaded on 2016-01). This has caused dpkg-shlibdeps to ignore some of those symbols and potentially end up generating version restrictions that are less than required. (This was dpkg bug #1000421.) So this involves shared libraries using versioned symbols, for symbols that are objects (variables instead of functions or methods), on architectures that emit copy relocations for these. On my checks these were at least any-amd64, hppa and m68k. A small example on linux-amd64: ,--- copyrel.c --- #include <unistd.h> int main() { return optind; } `--- ,--- (stretch) --- $ make copyrel $ objdump -R copyrel | grep R_[^ ]*_COPY 0000000000201028 R_X86_64_COPY optind@@GLIBC_2.2.5 `--- ,--- (sid) --- $ make copyrel $ objdump -R copyrel | grep R_[^ ]*_COPY 0000000000004028 R_X86_64_COPY optind@GLIBC_2.2.5 `--- What unearthed this was a recentish glibc upload that AFAIR has started merging its libpthread library into libc proper, and added a new symbol for a variable (__libc_single_threaded@GLIBC_2.32). I guess the archive should be checked for other instances of at least that glibc issue, because that can affect partial upgrades in a pretty nasty way (with programs being unable to be run-time linked). So that would imply any program that has been: * built against glibc >= 2.32-0experimental0 * built using binutils >= 2.26 * built using dpkg-dev < 1.21.0 * containing a copy reloc for __libc_single_threaded: objdump -R $prog | grep 'R_[^ ]*_COPY .* __libc_single_threaded' Most of this information should be available at least from the .buildinfo files. This could have affected other programs using other versioned variables from other shared libraries, for quite some time, but not that many shared libraries use versioned symbols, but checking that would imply more effort to detect. :/ Thanks, Guillem