968710">

Debian Bug report logs - #968710
dh_strip: build-ID-based debug symbols have file conflicts for duplicate private shared libraries

version graph

Package: debhelper; Maintainer for debhelper is Debhelper Maintainers <debhelper@packages.debian.org>; Source for debhelper is src:debhelper (PTS, buildd, popcon).

Reported by: Simon McVittie <smcv@debian.org>

Date: Thu, 20 Aug 2020 14:03:01 UTC

Severity: normal

Found in version debhelper/13.2

Reply or subscribe to this bug.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>:
Bug#968710; Package debhelper. (Thu, 20 Aug 2020 14:03:03 GMT) (full text, mbox, link).


Acknowledgement sent to Simon McVittie <smcv@debian.org>:
New Bug report received and forwarded. Copy sent to Debhelper Maintainers <debhelper@packages.debian.org>. (Thu, 20 Aug 2020 14:03:03 GMT) (full text, mbox, link).


Message #5 received at submit@bugs.debian.org (full text, mbox, be confused with the libgd2 graphics library, which is unrelated). > libgd is not API-stable, so a system-wide shared copy is undesirable > (and is not required by Debian Policy §4.13, because it is "explicitly > intended to be used in this way"). Normally the copy bundled with a > dependent project would be statically linked into the dependent project, > but gnome-documents and gnome-books are written in JavaScript and use > GObject-Introspection to call into libgd, which means it has to be built > as a shared library. Each app installs its copy into a separate private > library directory, which works fine. > > At the moment gnome-documents and gnome-books happen to have identical > libgd source code, although this is by no means guaranteed in future > releases. They are built into binaries that differ, but the build-ID is > identical (presumably the code they contain doesn't differ in any way > that matters for debugging), so -documents-dbgsym and -books-dbgsym > have an undeclared conflict and cannot be co-installed. For now I'm > probably going to work around this by disabling the automatic debug > symbols packages. > > Another place where I've seen this happen is that openarena and > openarena-server both ship the "game rules" for OpenArena, qagame*.so, > which is a dlopen()'d loadable module. This is duplication, but > I don't really want to bloat the Packages file by separating out an > openarena-common package to save 800K of installed size, particularly when > that's insignificant next to the 400M+ game data. I worked around this > by building a separate server-side qagame*.so with a different version > number string (0.8.8+dfsg-4/Debian/server vs. 0.8.8+dfsg-4/Debian) > and otherwise identical contents. > > Possible solutions: > > * perturb the build-ID somehow, similar to my workaround with the > (user-facing) version number string in openarena-server; > > * in dh_strip, make it possible to go back to path-based filenames in > /usr/lib/debug; > > * in dpkg, extend the reference-counting for identical files in > Multi-Arch: same packages to cover any identical file; > > * deploy detached debug symbols in a way that is not dpkg-based > > Any ideas? > > Thanks, > smcv &In-Reply-To=<20200820135840.GA674070@espresso.pseudorandom.co.uk>">reply):

From: Simon McVittie <smcv@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: dh_strip: build-ID-based debug symbols have file conflicts for duplicate private shared libraries
Date: Thu, 20 Aug 2020 14:58:40 +0100
Package: debhelper
Version: 13.2
Severity: normal
File: /usr/bin/dh_strip

Since compat level 9, debhelper uses build-ID-based detached debug symbols,
which are normally A Good Thing.

However, if two packages contain the same private shared library or
loadable module, and it's 100% reproducible, it can end up with the same
build-ID, causing those packages' detached debug symbols to collide.

One place where this legitimately happens is gnome-documents and
gnome-books, which both contain a copy of the libgd "copylib" (not to
be confused with the libgd2 graphics library, which is unrelated).
libgd is not API-stable, so a system-wide shared copy is undesirable
(and is not required by Debian Policy §4.13, because it is "explicitly
intended to be used in this way"). Normally the copy bundled with a
dependent project would be statically linked into the dependent project,
but gnome-documents and gnome-books are written in JavaScript and use
GObject-Introspection to call into libgd, which means it has to be built
as a shared library. Each app installs its copy into a separate private
library directory, which works fine.

At the moment gnome-documents and gnome-books happen to have identical
libgd source code, although this is by no means guaranteed in future
releases. They are built into binaries that differ, but the build-ID is
identical (presumably the code they contain doesn't differ in any way
that matters for debugging), so -documents-dbgsym and -books-dbgsym
have an undeclared conflict and cannot be co-installed. For now I'm
probably going to work around this by disabling the automatic debug
symbols packages.

Another place where I've seen this happen is that openarena and
openarena-server both ship the "game rules" for OpenArena, qagame*.so,
which is a dlopen()'d loadable module. This is duplication, but
I don't really want to bloat the Packages file by separating out an
openarena-common package to save 800K of installed size, particularly when
that's insignificant next to the 400M+ game data. I worked around this
by building a separate server-side qagame*.so with a different version
number string (0.8.8+dfsg-4/Debian/server vs. 0.8.8+dfsg-4/Debian)
and otherwise identical contents.

Possible solutions:

* perturb the build-ID somehow, similar to my workaround with the
  (user-facing) version number string in openarena-server;

* in dh_strip, make it possible to go back to path-based filenames in
  /usr/lib/debug;

* in dpkg, extend the reference-counting for identical files in
  Multi-Arch: same packages to cover any identical file;

* deploy detached debug symbols in a way that is not dpkg-based

Any ideas?

Thanks,
    smcv



Information forwarded to debian-bugs-dist@lists.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>:
Bug#968710; Package debhelper. (Fri, 05 Feb 2021 11:30:05 GMT) (full text, mbox, link).


Acknowledgement sent to Matthias Klose <doko@debian.org>:
Extra info received and forwarded to list. Copy sent to Debhelper Maintainers <debhelper@packages.debian.org>. (Fri, 05 Feb 2021 11:30:05 GMT) (full text, mbox, link).


Message #10 received at 968710@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@debian.org>
To: 968710@bugs.debian.org, Simon McVittie <smcv@debian.org>
Subject: Re: dh_strip: build-ID-based debug symbols have file conflicts for duplicate private shared libraries
Date: Fri, 5 Feb 2021 12:26:53 +0100
proposed solution at https://bugs.debian.org/981245



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Jan 31 00:52:12 2025; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU General Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.