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
