Bug#33536: huge libc-dbg package (32MB deb, unpacks to 120+ MB)

[Zack Weinberg <zack@rabi.columbia.edu>]

> RM> I don't think it's useful to have the debugging symbols in the _p
> RM> libs.  Those are for profiling, not for debugging.  You don't
> RM> need to want to profile or debug libc itself to want the _p
> RM> libs--you need them if you want to profile your program's calls
> RM> into libc.  For that matter, I think the _p libs should be in a
> RM> separate profile package rather than the dbg package (redhat has
> RM> a separate glibc-profile package).

The upstream source is configured by default to put debug symbols in
everything.  You might be able to override it with a `configparms'
file in (I think) the source directory.  Something like this:

CFLAGS-.op = -pg -g0

Or just strip the _p libraries.

> RM> I'm not sure that it's useful to have debugging symbols for libc
> RM> in the _g libs either, but maybe that's supposed to be the point
> RM> of them.  But perhaps the point of them is just to be surely not
> RM> built with -fomit-frame-pointer, so you can get backtraces to
> RM> your own code if your program crashes inside libc.  Any
> RM> distributed binaries with debugging symbols for libc seems kind
> RM> of pointless to me.  The only person who would want them is
> RM> someone debugging libc, who will just build it themselves.

I don't believe Debian compiles libc.so with -fomit-frame-pointer
(Joel, please correct me if I'm wrong).  The point of the _g
libraries IMO is to be able to get a backtrace with arguments, which
is often more useful than a bare backtrace.

I'd definitely like to see separate profiling packages.

zw