Bug#1008184: nmu: unknown packages affected by dpkg-dev bug #1000421
On Wed, Mar 23, 2022 at 11:29:48PM +0100, Guillem Jover wrote:
>...
> 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).
The merging only happens in 2.34 (currently in experimental),
but this new way of detecting multithreading was added in 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
FTR, this seems to be a 2 month window (give or take a few days due to
buildd chroots being updated only twice per week):
https://tracker.debian.org/news/1255840/accepted-glibc-232-1-source-into-unstable/
https://tracker.debian.org/news/1284072/accepted-dpkg-1210-source-into-unstable/
> * 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.
Relevant is also that the binary packages do not already have
dependencies on libc6 >= 2.32 for other reasons.
>...
> 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. :/
Versioned symbols are common, but:
>...
> So this involves shared libraries using versioned symbols, for symbols
> that are objects (variables instead of functions or methods),
>...
Global variables as part of a library API are usually considered bad
practice, and then you'd need a case where such a new variable is
used but no new function.
__libc_single_threaded is special, and looking at cppcheck the problem
occurs in practice mainly due to libstdc++ using it for atomics in its
headers when available.
> Thanks,
> Guillem
cu
Adrian
Reply to: