mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-03-06 06:14:47 +00:00
Small fixups across the board.
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@2883 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
parent
6952b96fa2
commit
1cb7ced1c4
@ -40,10 +40,10 @@
|
||||
<title>Stripping</title>
|
||||
<?dbhtml filename="stripping.html" dir="chapter05"?>
|
||||
|
||||
<para>If your LFS partition is rather small, you will be glad to learn that you
|
||||
can throw away some unnecessary things. The executables and libraries you have
|
||||
built so far contain about 130 MB of unneeded debugging symbols. Remove those
|
||||
symbols like this:</para>
|
||||
<para>The steps in this section are optional. If your LFS partition is rather
|
||||
small, you will be glad to learn that you can throw away some unnecessary
|
||||
things. The executables and libraries you have built so far contain about 130 MB
|
||||
of unneeded debugging symbols. Remove those symbols like this:</para>
|
||||
|
||||
<para><screen><userinput>strip --strip-unneeded /tools/{,s}bin/*
|
||||
strip --strip-debug /tools/lib/*</userinput></screen></para>
|
||||
|
@ -40,7 +40,7 @@ patch -Np1 -i ../gcc-&gcc-specs-version;.patch</userinput></screen></para>
|
||||
briefly earlier, but a slightly more in-depth explanation of the fixincludes
|
||||
process is warranted here. Under normal circumstances, the GCC fixincludes
|
||||
script scans your system for header files that need to be fixed. It might find
|
||||
that the Glibc header files on your host system need to be fixed, fix them and
|
||||
that some Glibc header files on your host system need to be fixed, fix them and
|
||||
put them in the GCC private include directory. Then, later on in Chapter 6,
|
||||
after we've installed the newer Glibc, this private include directory would be
|
||||
searched before the system include directory, resulting in GCC finding the
|
||||
|
@ -73,12 +73,12 @@ libpng, libz, and so forth).</para></listitem>
|
||||
<para>During this stage you might see the following warning:</para>
|
||||
|
||||
<blockquote><screen>configure: WARNING:
|
||||
*** These auxiliary programs are missing or incompatible versions: autoconf
|
||||
*** These auxiliary programs are missing or incompatible versions: msgfmt
|
||||
*** some features will be disabled.
|
||||
*** Check the INSTALL file for required versions.</screen></blockquote>
|
||||
|
||||
<para>The missing or incompatible <filename>autoconf</filename> program is
|
||||
harmless and doesn't cause any problems.</para>
|
||||
<para>The missing or incompatible <filename>msgfmt</filename> program is
|
||||
generally harmless and shouldn't cause us any problems.</para>
|
||||
|
||||
<para>Continue with compiling the package:</para>
|
||||
|
||||
|
@ -27,7 +27,7 @@ like vim and less to operate properly. If you need other variables present,
|
||||
such as CFLAGS or CXXFLAGS, this is a good place to set them again.</para>
|
||||
|
||||
<para>Also note the use of the set +h directive. This tells bash to not use
|
||||
it's internal path hashing. Without this directive, bash will remember paths
|
||||
its internal path hashing. Without this directive, bash will remember paths
|
||||
to binaries. Since as we go thru chapter 6, we want to use our newly compiled
|
||||
binaries as soon as they are installed, we turn off this function.</para>
|
||||
|
||||
|
@ -15,13 +15,17 @@ 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 faster, but they
|
||||
may also cause compilation difficulties. If a package refuses
|
||||
to compile when using optimization, try to compile it without
|
||||
optimization and see if the problem goes away.</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
|
||||
|
Loading…
Reference in New Issue
Block a user