Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A commonly done task is to profile things. Profiling is rarely done on debug builds. Ubuntu seems to either give you the choice of stripped optimized executables or debug builds. I've run into this on both libc and vmlinux-... which I extracted out of vmlinuz. After I extracted it I found that it was stripped.

Do I have to build my own system libraries just to get symbols? Do symbols really take that much memory or disk? The full debug version lib libc is only 7.6MB's and is shared across all running processes! The optimized version, with symbols should be similarly tiny. Why are these stripped?

What apt-get do I need for libc and vmlinuz to get optimized non-stripped versions?

share|improve this question
This should be rephrased so that it is more easily answerable -- because this is a Q&A site, questions need to be clear (with one per post) for good answers to appear. – belacqua Aug 22 '12 at 15:14

By policy, Ubuntu builds everything with debugging symbols enabled, and then we strip these symbols out of the binary packages. For almost all users, these symbols are wasted space, and for some things this can be a significant amount of wasted space and download time. For example, Firefox and LibreOffice have nearly a gig of debugging symbols, and you'll have noticed that the kernel debug symbols are hundreds of megabytes.

For the small number of people who need these symbols - and when you need them, you really need them - we take all the debugging symbols out of the binary packages and stick them in a -dbgsym package. See Debugging Program Crash for how to get at the dbgsym repository.

Some packages don't have a -dbgsym package. Mostly these are packages which have a -dbg package already, or don't have any debugging symbols from the build - either because they don't actually have any executable code, or (sometimes) because of a build bug.

share|improve this answer
So is libc in libc6-dbg optimized but not-stripped(either -O or -g -O) OR debug built NOT optimized and not-stripped. If the libc6-dbg is debug only without the -O then doing profiling on a benchmark becomes impractical. NOTE: There isn't a libc6-dbgsym – Dan Wood Aug 16 '12 at 19:59
NOTE: One should distinguish between "debug symbols" and the basic stuff seen by "nm" in a non-debug build. Unfortunately, strip removes both. Even then, the cross reference between function and address remained, otherwise runtime linking wouldn't work. On systems that have "dump" I could still get at function address to function name info even when nm said it was stripped. Unfortunately stack tracing and profiling can't use this info. – Dan Wood Aug 16 '12 at 20:51
Almost always the -dbg package simply contains the stripped symbols. There are a few exceptions (libglib2.0-0-refdbg is an example), but libc6 isn't one of them. You can tell because the package contains only files in /usr/lib/debug. – RAOF Aug 18 '12 at 3:07
I really like this answer. Perhaps you could add something about apt-get build-dep, apt-get source, and simply disable optimization in the makefile/deb folder – hbdgaf Aug 22 '12 at 1:38

Debugging symbols are usually made into a separate package that can be installed along side the actual package. They usually have a -dbg appended on the end.

For example, the package mythtv is named


and the debugging symbols are located in


So you would need to have both of those packages installed to debug MythTV

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.