mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-01-18 21:17:38 +00:00
1cb7ced1c4
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@2883 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
42 lines
2.2 KiB
XML
42 lines
2.2 KiB
XML
<sect1 id="ch06-introduction">
|
|
<title>Introduction</title>
|
|
<?dbhtml filename="introduction.html" dir="chapter06"?>
|
|
|
|
<para>In this chapter we enter the building site, and start
|
|
constructing our LFS system in earnest. That is, we chroot into
|
|
our temporary mini Linux system, create some auxiliary things,
|
|
and then start installing all the packages, one by one.</para>
|
|
|
|
<para>The installation of all this software is pretty straightforward,
|
|
and you will probably think it would be much shorter to give here
|
|
the generic installation instructions and explain in full only the
|
|
installation of those packages that require an alternate method.
|
|
Although we agree with that, we nevertheless choose to give the
|
|
full instructions for each and every package, simply to minimize
|
|
the possibilities for mistakes.</para>
|
|
|
|
<para>If you plan to use compiler optimizations in this chapter, take a look at
|
|
the optimization hint at <ulink url="&hints-root;optimization.txt"/>. Compiler
|
|
optimizations can make a program run a touch faster, but they may also cause
|
|
compilation difficulties and even problems when running the program. If a
|
|
package refuses to compile when using optimization, try to compile it without
|
|
optimization and see if the problem goes away. Even if the package does compile
|
|
when using optimization, there is the risk it may have been compiled
|
|
incorrectly due to compiler bugs or whatever. In short, the small gains achieved
|
|
in using compiler optimization are generally outweighed by the risk. First time
|
|
builders of LFS are encouraged not to bother. Your system will still be plenty
|
|
fast enough and very stable at the same time.</para>
|
|
|
|
<para>The order in which packages are installed in this chapter has
|
|
to be strictly followed, to ensure that no program gets a path referring
|
|
to <filename class="directory">/tools</filename> hard-wired into it.
|
|
For the same reason, <emphasis>do not </emphasis> compile packages
|
|
in parallel. Compiling in parallel may save you some time (especially on
|
|
dual-CPU machines), but it could result in a program containing a
|
|
hard-wired path to <filename class="directory">/tools</filename>,
|
|
which will cause the program to stop working when that directory
|
|
is removed.</para>
|
|
|
|
</sect1>
|
|
|