Most programs and libraries are by default compiled with debugging symbols and optimizing level 2 (gcc options -g and -O2) and are compiled for a specific cpu. On intel platforms software is compiled for i386 processors by default. If you don't wish to run software on other machines other than your own, you might want to change the default compiler options so that they will be compiled with a higher optimization level, no debugging symbols and generate code for your specific architecture. Let me first explain what debugging symbols exactly are.
A program compiled with debugging symbols means you can run a program or library through a debugger and the debugger's output will be user friendlier. These debugging symbols also enlarge the program or library significantly.
To remove debugging symbols from a binary (must be an a.out or ELF binary) run strip --strip-debug filename You can use wild cards if you need to strip debugging symbols from multiple files (use something like strip --strip-debug $LFS/usr/bin/*). Another, easier, options is to just not compile programs with debugging symbols. Most people will probably never use a debugger on software, so by leaving those symbols out you can save a lot of diskspace.
Before you wonder if these debugging symbols would make a big difference, here are some statistics:
A static Bash binary with debugging symbols: 2.3MB
A static Bash binary without debugging symbols: 645KB
A dynamic Bash binary with debugging symbols: 1.2MB
A dynamic Bash binary without debugging symbols: 478KB
$LFS/lib and $LFS/usr/lib (glibc and gcc files) with debugging symbols: 87MB
$LFS/lib and $LFS/usr/lib (glibc and gcc files) without debugging symbols: 16MB
Sizes may vary depending on which compiler was used and which C library version was used to link dynamic programs against, but your results will be similar if you compare programs with and without debugging symbols. After I was done with this chapter and stripped all debugging symbols from all LFS binaries and libraries I regained a little over 102 MB of disk space. Quite the difference. The difference would be even greater when this would be done at the end of this book when everything is installed.
There are a few ways to change the default compiler options. One way is to edit every Makefile file you can find in a package, look for the CFLAGS and CXXFLAGS variables (a well designed package uses the CFLAGS variable to define gcc compiler options and CXXFLAGS to define g++ compiler options)) and change the values. Packages like binutils, gcc, glibc and others have a lot of Makefile files in a lot of subdirectories so this would take a lot of time to do. Instead there's an easier way to do things: create the CFLAGS and CXXFLAGS environment variables and tell the make program that the environment variable takes precedence over variables in the Makefile files (that's accomplished by passing the -e option to make).
The optimization options presented here are a minimal set of optimizations. This is to ensure that it will work on most platforms. Run the following command in the shell that you are going to use to compile the software in. If you exit the shell to, for example, pause compilation and continue later, make sure you execute the following command again when you start compiling again (you only need to execute it once when you open a new virtual console, xterm, Eterm or some other terminal emulation program). Run the following command to setup the environment variables:
root:~# export CFLAGS="-O3 -mcpu=xxx -march=yyy"
root:~# export CXXFLAGS="-O3 -mcpu=xxx -march-yyy"
Replace xxx and yyy with the appropriate cpu idenfifiers such as i686.
Please note that overriding the CFLAGS and CXXFLAGS values can cause problems. Some packages define marco's and other options in the CFLAGS and CXXFLAGS variables. Our environment variables don't contain those other definitions that might be needed by other packages. I've tried to sort this out and where needed the commands in this book don't override the Makefile file variables, but there is always the chance I have overlooked a few. Or a package seemingly compiled fine but behaves strangly when it's executed in some way. If a program behaves out of the ordinary recompile that package without these optimization flags (by just not passing the -e option to the make command(s)) and see if that helps.