r973 - trunk

tushar at linuxfromscratch.org tushar at linuxfromscratch.org
Mon Aug 1 19:38:55 PDT 2005


Author: tushar
Date: 2005-08-01 20:38:54 -0600 (Mon, 01 Aug 2005)
New Revision: 973

Added:
   trunk/small-lfs.txt
Log:
Added Hint: small-lfs

Added: trunk/small-lfs.txt
===================================================================
--- trunk/small-lfs.txt	2005-08-02 02:38:32 UTC (rev 972)
+++ trunk/small-lfs.txt	2005-08-02 02:38:54 UTC (rev 973)
@@ -0,0 +1,146 @@
+AUTHOR:      Joachim Beckers <jbeckers at 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.




More information about the hints mailing list