huge libc-dbg package (32MB deb, unpacks to 120+ MB)
The libc0.2-dbg_2.0.110-0.1.deb package is 32MB (more than a third of the
total space for all the hurd-specific .deb packages). It installs over 120MB.
I think this is unreasonable.
What makes it so huge is the static libraries with debugging symbols.
These are particularly huge on the Hurd because of extra headers and
declarations, as well as there being more code in libc on the hurd than on
linux.
It includes -g symbols for the libraries themselves in both the lib*_p.a
libraries and the lib*_g.a libraries. I'm not entirely sure what the
purpose of the libc-dbg package is, but I don't think this is necessary.
Does the linux version of the libc-dbg package for glibc-2.1 include full
debugging symbols for libc, and in the _p versions?
I don't think it's useful to have the debugging symbols in the _p libs.
Those are for profiling, not for debugging. You don't need to want to
profile or debug libc itself to want the _p libs--you need them if you want
to profile your program's calls into libc. For that matter, I think the _p
libs should be in a separate profile package rather than the dbg package
(redhat has a separate glibc-profile package).
I'm not sure that it's useful to have debugging symbols for libc in the _g
libs either, but maybe that's supposed to be the point of them. But
perhaps the point of them is just to be surely not built with
-fomit-frame-pointer, so you can get backtraces to your own code if your
program crashes inside libc. Any distributed binaries with debugging
symbols for libc seems kind of pointless to me. The only person who would
want them is someone debugging libc, who will just build it themselves.
Reply to: