Actually stripping debug information (or compiling without -g) makes it very difficult to troubleshoot a problem in production, where the binary might be deployed at a customer's site, and where the source code might not be available (firewall, no network connection, ...) The additional information is encoded into the ELF header, but ignored by the runtime linker, so it does not hurt the performance of the program.
The space savings come nowhere close to the benefit of having the additional information available when debugging.
Some operating systems, for example SmartOS, and any other OS based off of the illumos's source code, even inject the entire source code into the ELF binary and library in a special compact format during the build with the ctfconvert(1ONBLD) / ctfmerge(1ONBLD) tools[1][2].
If you are ever considering stripping the binary just to save some disk space but do not have a good reason for it (like building for a space-constrained appliance), please abstain from doing so; every developer and engineer trying to debug your program will be thankful to you if you do not remove the debugging information.
The space savings come nowhere close to the benefit of having the additional information available when debugging.
Some operating systems, for example SmartOS, and any other OS based off of the illumos's source code, even inject the entire source code into the ELF binary and library in a special compact format during the build with the ctfconvert(1ONBLD) / ctfmerge(1ONBLD) tools[1][2].
If you are ever considering stripping the binary just to save some disk space but do not have a good reason for it (like building for a space-constrained appliance), please abstain from doing so; every developer and engineer trying to debug your program will be thankful to you if you do not remove the debugging information.
[1] http://lethargy.org/~jesus/writes/mdb-ctf-dwarf-and-other-an...
[2] http://dtrace.org/blogs/rm/2013/11/14/userland-ctf-in-dtrace...