On Sun, Feb 06, 2005 at 12:36:55AM +0100, Josselin Mouette wrote:
> With the increasing numbers of libraries, especially libraries in
> development, we have an increasing number of -dbg packages in the
> archive. As they are useful only for debugging, and not for the average
> user, I think they are mostly cluttering the Packages file and mirror
> space.
>
> Practically speaking, there is a very small chance, when you find a bug
> in a library, that the -dbg package is available. This is worse if the
> bug is in a binary and not a library; you often end up rebuilding a
> debugging version of the package for the submitting user. In fact, the
> availability of a -dbg version could be useful for every
> architecture-dependent package.
>
> The most obvious solution I can come up for this issue is to build a
> separate tree with DEB_BUILD_OPTIONS="noopt nostrip", at least for i386.
> That means having a dedicated machine that would be used to run a buildd
> for that. Unfortunately, I don't have such a machine, and I don't know
> of an available i386 project machine.
>
> Are there some people here who'd be interested, or who could point me to
> available resources? If not, do you have other ideas to make debugging
> packages easily available?
It was brought up on IRC, a couple of weeks ago (my apologies, but I don't
recall who brought it up, nor do I have a log) that it is now possible
to strip debugging information from a binary or library, and keep the
debugging information in a separate file. When invoking GDB (I don't know
about other debuggers, yet, but it seems like an easy thing to add as an
extension given the way it's done), it checks first for debugging symbols
directly, then for the presence of a pointer to a file to find them in.
If it finds the pointer, it checks that (using a short search path to try
more than just the flat name, generally), and if found, loads the debugging
symbols from there.
Switching dh_strip to use this would provide a number of benefits:
1) It would become possible (I'm not sure if it would be *sane*) to
include debugging information for all binaries and libraries in a fairly
straightforward manner - and one which could target a directory that, like
/usr/share/doc or others, can safely be purged by the local admin if they
don't want the disk bloat.
2) Even if only applied to -dbg packages, it would make -dbg packages
significantly smaller (only needing the debug symbols file, not a complete
secondary copy of the library).
3) Allows you to generate a -dbg package without doing a second build-run
over the libraries or having to do strange convolutions to package both
stripped and unstripped libraries without duplicating the build.
4) Allows you to use debugging on any library without having to restart
the application with a suitable LD_LIBRARY_PATH (nor does it run afoul of
things that muck with library search paths or don't permit the environment
to override it for security reasons).
I believe the proper Google search for more details would be "gdb separate
debug files".
--
Joel Aelwyn <fenton@debian.org> ,''`.
: :' :
`. `'
`-
Attachment:
signature.asc
Description: Digital signature