small-lfs.txt

   1 AUTHOR:      Joachim Beckers <jbeckers@linuxfromscratch.org>
   2 DATE:        2005-07-31
   3 LICENSE:     GNU Free Documentation License version 1.2
   4
   5 SYNOPSIS:    Tips and tricks for creating a small LFS system.
   6
   7 PRIMARY URI: http://jbeckers.webhop.org/en/hints.html
   8
   9 DESCRIPTION:
  10 A freshly built LFS system is relatively small, but still, in certain
  11 occasions, it can take up too much disk space. This hint provides some easy
  12 and more advanced tips and tricks to strip down an LFS system, so that it will
  13 fit on a smaller harddisk.
  14
  15 PREREQUISITES:
  16 Since certain optimizations can only be done at build time, I strongly advise
  17 you to read the entire hint before you start building your LFS system, . This
  18 does not mean you can't use this hint to strip down an existing LFS system, but
  19 there might be some difficulties.
  20 Secondly I assume that readers of this hint have some experience with LFS and
  21 with Linux and its tools in general.
  22 And of course, as you will know for sure: make back-ups before you do anything
  23 potentially harmful to your system!
  24
  25 HINT:
  26
  27     Compile time optimizations:
  28     ===========================
  29 Building up a small LFS system already starts at compile time. The compiler and
  30 linker have some features that allow them to create smaller binaries/libraries.
  31 To make use of these features, adjust your CFLAGS. During the LFS build, this
  32 should be done when setting up the environment and right after entering chroot.
  33
  34 There are discussions about which CFLAGS to use. The truth is that no one knows
  35 exactly. On top of that, every system is different and requires different
  36 optimizations. The best thing to do is to read up on compiler optimizations and
  37 decide for yourself. However, the most used and considered safe CFLAGS are:
  38  -Os, which tells the compiler to optimize for size,
  39  -fomit-frame-pointer, which turns of frame pointers (a debugging feature),
  40  -march=<cpu-architecture>, which turns on cpu-specific optimizations,
  41  -pipe, which tells gcc not to create temporary files but pipe data. Use with
  42         caution, as it also makes gcc use more RAM.
  43
  44 Not only CFLAGS can reduce the size of binaries. There are other way to
  45 accomplish the same result. Setting the environment variable CC to "gcc -s"
  46 will cause gcc to strip binaries as they are created. Setting LDFLAGS to "-s"
  47 will do the same thing for libraries.
  48
  49 Notes: - A good starting point to learn about gcc and its options is this hint:
  50          http://www.linuxfromscratch.org/hints/downloads/files/optimization.txt
  51        - If you want the full reference, check out the online gcc docs:
  52          http://gcc.gnu.org/onlinedocs/
  53
  54 If you don't use NLS (a.k.a. locales), you can configure packages with
  55 --disable-nls to conserve some room.
  56
  57 For the three largest packages in the LFS book (gcc, glibc and the kernel)
  58 there are plenty of ways to slim them down.
  59
  60 Some compilers in the GNU Compiler Collection are very rarely used. If you
  61 think you don't need them, remove the sources before the build. e.g.:
  62     # rm -rf libjava libobjc gcc/ada gcc/f gcc/java gcc/objc
  63
  64 The other big package, glibc, is a bit harder to strip down. You can start by
  65 adding "--enable-omitfp --enable-kernel=<kernel-version>" as extra configure
  66 arguments. The former turns off frame pointers, while the latter disables code
  67 that is needed for compatibility with kernels older than your current kernel.
  68 After the build has finished, you can do:
  69     # rm libc_g.a
  70 The library libc_g.a contains debugging symbols and can safely be removed.
  71
  72 Lastly, the kernel. The easiest way the create a small kernel is without any
  73 doubt, by excluding as much as possible from your kernel's configuration. Also,
  74 If you compile a keymap into the kernel, other keymaps can be removed later on.
  75
  76     Run time optimizations:
  77     =======================
  78 Stripping binaries and libraries can free a lot of space. Use the instructions
  79 provided in the LFS book to do this. To find out whether there are still
  80 unstripped libraries or binaries, run the following command:
  81     # find / -exec file {} \; | grep "not stripped"
  82 These can be stripped as well.
  83
  84 Note: Do not strip any binary or library that's currently in use. It's possible
  85       that the program using it will crash.
  86
  87 Compressing man and info pages is a second big win. For the most convenient way
  88 of compressing man and info pages, see the compressdoc.sh script that comes
  89 with the BLFS book.
  90
  91 If you know all man and info pages by heart, you can remove them ;-). Other
  92 kinds of documentation (licenses, READMEs, ...) can safely be removed as well.
  93
  94 If you have chosen to build all packages without support for locales, you can
  95 remove everything in /usr/share/locale and /usr/lib/locale.
  96
  97 If you have chosen to compile your keymap into the kernel, the same applies for
  98 /usr/share/kbd.
  99
 100 If you copy your timezone to /etc/localtime instead of making a symlink, all of
 101 /usr/share/zoneinfo can be removed as well.
 102
 103     Extreme optimizations:
 104     ======================
 105 As the title says, these are extreme optimizations that can easily break your
 106 system. They require extensive knowledge of the internals of a linux system.
 107 Use them at your own risk.
 108
 109 Note: It's a good idea to take back-ups of your system before you try any of
 110       these optimizations.
 111
 112 Removing terminfo files that you don't use, can free up some space. For
 113 instance, you could remove all the terminfo files except for linux and xterm.
 114 However, this requires knowledge about terminal types. If you do not know
 115 what to keep and what to remove, leave the files alone.
 116
 117 Secondly, almost all directories in /usr/share can be removed, even if you use
 118 the programs that go with them. Take a look at the contents and decide whether
 119 you want to take the risk of removing files that look unimportant. Again, if
 120 you're not sure if you need the files or not, leave them be.
 121
 122 Next up is the hard part. Take a look at each binary installed in your $PATH.
 123 If you don't know what a binary does, then read the man page (if you still have
 124 it installed ;-)), and decide if you need it or not. If you know what it does,
 125 and you know that you don't need it, then remove it. There will be some
 126 binaries that don't have man pages, don't offer any help, and who's purpose is
 127 not obvious. Play it safe and leave it be in that case.
 128
 129 It's not so easy removing stuff from /usr/lib, as it is not obvious what is
 130 needed. It is safe to remove the debugging and profiling libraries (those
 131 ending in _g.a or _p.a). They can be removed if you do not plan to debug or
 132 profile code that uses them.
 133
 134 That's it. If you've followed the instructions I provided, your system will now
 135 be significantly smaller. Congratulations!
 136
 137 ACKNOWLEDGMENTS:
 138 Thanks to James Smaby, the author of the lowspace and stripped-down hints.
 139
 140 CHANGELOG:
 141 [2005-07-31]
 142 * Maintainership taken over.
 143 * Merged the lowspace and stripped-down hints into one
 144 * Various cleanups and updates
 145 * Converted to new hint format.
 146 * Published the hint on my website.