Bug#33536: huge libc-dbg package (32MB deb, unpacks to 120+ MB)
Package: libc0.2-dbg
Version: 2.0.110-0.1
I am forwarding a message from Roland McGrath, accompanied with my own
comments. It's really his reported bug, but he doesn't have time to
learn the BTS, so I'm submitting it.
>>>>> Roland McGrath writes:
RM> The libc0.2-dbg_2.0.110-0.1.deb package is 32MB (more than a
RM> third of the total space for all the hurd-specific .deb
RM> packages). It installs over 120MB. I think this is
RM> unreasonable.
RM> What makes it so huge is the static libraries with debugging
RM> symbols. These are particularly huge on the Hurd because of
RM> extra headers and declarations, as well as there being more code
RM> in libc on the hurd than on linux.
RM> It includes -g symbols for the libraries themselves in both the
RM> lib*_p.a libraries and the lib*_g.a libraries. I'm not entirely
RM> sure what the purpose of the libc-dbg package is, but I don't
RM> think this is necessary.
RM> Does the linux version of the libc-dbg package for glibc-2.1
RM> include full debugging symbols for libc, and in the _p versions?
Yes, the Linux version also includes debugging symbols.
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).
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 have to agree with Roland here on both points. Has there been
thought to creating a separate libc-profile (without debugging
symbols), and/or a libc-dbg without symbols (but with a frame
pointer)?
--
Gordon Matzigkeit <gord@fig.org> //\ I'm a FIG (http://www.fig.org/)
Lovers of freedom, unite! \// I use GNU (http://www.gnu.org/)
[Unfortunately, www.fig.org is broken. Please stay tuned for details.]
Reply to: