AUTHOR:      Joachim Beckers <jbeckers@linuxfromscratch.org>
DATE:        2005-07-31
LICENSE:     GNU Free Documentation License version 1.2

SYNOPSIS:    Tips and tricks for creating a small LFS system.

PRIMARY URI: http://jbeckers.webhop.org/en/hints.html

DESCRIPTION:
A freshly built LFS system is relatively small, but still, in certain
occasions, it can take up too much disk space. This hint provides some easy
and more advanced tips and tricks to strip down an LFS system, so that it will
fit on a smaller harddisk.

PREREQUISITES:
Since certain optimizations can only be done at build time, I strongly advise
you to read the entire hint before you start building your LFS system, . This
does not mean you can't use this hint to strip down an existing LFS system, but
there might be some difficulties.
Secondly I assume that readers of this hint have some experience with LFS and
with Linux and its tools in general.
And of course, as you will know for sure: make back-ups before you do anything
potentially harmful to your system!

HINT:

    Compile time optimizations:
    ===========================
Building up a small LFS system already starts at compile time. The compiler and
linker have some features that allow them to create smaller binaries/libraries.
To make use of these features, adjust your CFLAGS. During the LFS build, this
should be done when setting up the environment and right after entering chroot.

There are discussions about which CFLAGS to use. The truth is that no one knows
exactly. On top of that, every system is different and requires different
optimizations. The best thing to do is to read up on compiler optimizations and
decide for yourself. However, the most used and considered safe CFLAGS are:
 -Os, which tells the compiler to optimize for size,
 -fomit-frame-pointer, which turns of frame pointers (a debugging feature),
 -march=<cpu-architecture>, which turns on cpu-specific optimizations,
 -pipe, which tells gcc not to create temporary files but pipe data. Use with
        caution, as it also makes gcc use more RAM.

Not only CFLAGS can reduce the size of binaries. There are other way to
accomplish the same result. Setting the environment variable CC to "gcc -s"
will cause gcc to strip binaries as they are created. Setting LDFLAGS to "-s"
will do the same thing for libraries.

Notes: - A good starting point to learn about gcc and its options is this hint:
         http://www.linuxfromscratch.org/hints/downloads/files/optimization.txt
       - If you want the full reference, check out the online gcc docs:
         http://gcc.gnu.org/onlinedocs/

If you don't use NLS (a.k.a. locales), you can configure packages with
--disable-nls to conserve some room.

For the three largest packages in the LFS book (gcc, glibc and the kernel)
there are plenty of ways to slim them down.

Some compilers in the GNU Compiler Collection are very rarely used. If you
think you don't need them, remove the sources before the build. e.g.:
    # rm -rf libjava libobjc gcc/ada gcc/f gcc/java gcc/objc

The other big package, glibc, is a bit harder to strip down. You can start by
adding "--enable-omitfp --enable-kernel=<kernel-version>" as extra configure
arguments. The former turns off frame pointers, while the latter disables code
that is needed for compatibility with kernels older than your current kernel.
After the build has finished, you can do:
    # rm libc_g.a
The library libc_g.a contains debugging symbols and can safely be removed.

Lastly, the kernel. The easiest way the create a small kernel is without any
doubt, by excluding as much as possible from your kernel's configuration. Also,
If you compile a keymap into the kernel, other keymaps can be removed later on.

    Run time optimizations:
    =======================
Stripping binaries and libraries can free a lot of space. Use the instructions
provided in the LFS book to do this. To find out whether there are still
unstripped libraries or binaries, run the following command:
    # find / -exec file {} \; | grep "not stripped"
These can be stripped as well.

Note: Do not strip any binary or library that's currently in use. It's possible
      that the program using it will crash.

Compressing man and info pages is a second big win. For the most convenient way
of compressing man and info pages, see the compressdoc.sh script that comes
with the BLFS book.

If you know all man and info pages by heart, you can remove them ;-). Other
kinds of documentation (licenses, READMEs, ...) can safely be removed as well.

If you have chosen to build all packages without support for locales, you can
remove everything in /usr/share/locale and /usr/lib/locale.

If you have chosen to compile your keymap into the kernel, the same applies for
/usr/share/kbd.

If you copy your timezone to /etc/localtime instead of making a symlink, all of
/usr/share/zoneinfo can be removed as well.

    Extreme optimizations:
    ======================
As the title says, these are extreme optimizations that can easily break your
system. They require extensive knowledge of the internals of a linux system.
Use them at your own risk.

Note: It's a good idea to take back-ups of your system before you try any of
      these optimizations.

Removing terminfo files that you don't use, can free up some space. For
instance, you could remove all the terminfo files except for linux and xterm.
However, this requires knowledge about terminal types. If you do not know
what to keep and what to remove, leave the files alone.

Secondly, almost all directories in /usr/share can be removed, even if you use
the programs that go with them. Take a look at the contents and decide whether
you want to take the risk of removing files that look unimportant. Again, if
you're not sure if you need the files or not, leave them be.

Next up is the hard part. Take a look at each binary installed in your $PATH.
If you don't know what a binary does, then read the man page (if you still have
it installed ;-)), and decide if you need it or not. If you know what it does,
and you know that you don't need it, then remove it. There will be some
binaries that don't have man pages, don't offer any help, and who's purpose is
not obvious. Play it safe and leave it be in that case.

It's not so easy removing stuff from /usr/lib, as it is not obvious what is
needed. It is safe to remove the debugging and profiling libraries (those
ending in _g.a or _p.a). They can be removed if you do not plan to debug or
profile code that uses them.

That's it. If you've followed the instructions I provided, your system will now
be significantly smaller. Congratulations!

ACKNOWLEDGMENTS:
Thanks to James Smaby, the author of the lowspace and stripped-down hints.

CHANGELOG:
[2005-07-31]
* Maintainership taken over.
* Merged the lowspace and stripped-down hints into one
* Various cleanups and updates
* Converted to new hint format.
* Published the hint on my website.
