[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1008184: marked as done (nmu: unknown packages affected by dpkg-dev bug #1000421)

Your message dated Sun, 18 Sep 2022 17:48:13 +0200
with message-id <Yyc9vWUaUo4dSZbN@ramacher.at>
and subject line Re: Bug#1008184: nmu: unknown packages affected by dpkg-dev bug #1000421
has caused the Debian Bug report #1008184,
regarding nmu: unknown packages affected by dpkg-dev bug #1000421
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1008184: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008184
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: important
User: release.debian.org@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

--- End Message ---
--- Begin Message --- 
On 2022-03-23 23:29:48 +0100, Guillem Jover wrote:
> Package: release.debian.org
> Severity: important
> User: release.debian.org@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'

I have scheduled rebuilds for this issue. I collected the relevant
packages from the first three conditions and rebuilt everything that
hasn't been built since. So there may be some builds that are not
strictly necessary.

Cheers
-- 
Sebastian Ramacher

--- End Message ---
Reply to: