gronod/lfs
1
0
Fork 0
mirror of https://git.linuxfromscratch.org/lfs.git synced 2025-06-19 03:39:20 +01:00
Code Issues Packages Projects Releases Wiki Activity

Changing a few SBUs.

Browse Source 
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3251 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Alex Gronenwoud 2004-02-14 14:53:12 +00:00
parent cd1ddd744e
commit c3dc67cdcf
7 changed files with 16 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
chapter05/chapter05.xml
View File

@ -155,7 +155,7 @@ will show you all the files successfully opened during the linking.</para>
checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</screen></blockquote> checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</screen></blockquote>
<para>This is important for the reasons mentioned above. It also demonstrates <para>This is important for the reasons mentioned above. It also demonstrates
that GCC's configure script does not search the $PATH directories to find which that GCC's configure script does not search the PATH directories to find which
tools to use. However, during the actual operation of <command>gcc</command> tools to use. However, during the actual operation of <command>gcc</command>
itself, the same search paths are not necessarily used. You can find out which itself, the same search paths are not necessarily used. You can find out which
standard linker <command>gcc</command> will use by running: standard linker <command>gcc</command> will use by running:
@ -169,7 +169,7 @@ information about the preprocessor, compilation and assembly stages, including
<para>The next package installed is Glibc. The most important considerations for <para>The next package installed is Glibc. The most important considerations for
building Glibc are the compiler, binary tools and kernel headers. The compiler building Glibc are the compiler, binary tools and kernel headers. The compiler
is generally no problem as Glibc will always use the <command>gcc</command> is generally no problem as Glibc will always use the <command>gcc</command>
found in a $PATH directory. The binary tools and kernel headers can be a little found in a PATH directory. The binary tools and kernel headers can be a little
more troublesome. Therefore we take no risks and use the available configure more troublesome. Therefore we take no risks and use the available configure
switches to enforce the correct selections. After the run of switches to enforce the correct selections. After the run of
<command>./configure</command> you can check the contents of the <command>./configure</command> you can check the contents of the
@ -525,10 +525,10 @@ problem is and correct it. There is no point in continuing until this is done.
First, redo the sanity check using <command>gcc</command> instead of First, redo the sanity check using <command>gcc</command> instead of
<command>cc</command>. If this works it means the <command>cc</command>. If this works it means the
<filename class="symlink">/tools/bin/cc</filename> symlink is missing. Revisit <filename class="symlink">/tools/bin/cc</filename> symlink is missing. Revisit
<xref linkend="ch-tools-gcc-pass1"/> and fix the symlink. Second, ensure your $PATH <xref linkend="ch-tools-gcc-pass1"/> and fix the symlink. Second, ensure your PATH
is correct. You can check this by running <userinput>echo $PATH</userinput> and is correct. You can check this by running <userinput>echo $PATH</userinput> and
verifying that <filename class="directory">/tools/bin</filename> is at the head verifying that <filename class="directory">/tools/bin</filename> is at the head
of the list. If the $PATH is wrong it could mean you're not logged in as user of the list. If the PATH is wrong it could mean you're not logged in as user
<emphasis>lfs</emphasis> or something went wrong back in <emphasis>lfs</emphasis> or something went wrong back in
<xref linkend="ch-tools-settingenviron"/>. Third, something may have gone wrong with <xref linkend="ch-tools-settingenviron"/>. Third, something may have gone wrong with
the specs file amendment above. In this case redo the specs file amendment the specs file amendment above. In this case redo the specs file amendment
@ -586,8 +586,9 @@ that it doesn't recognize their file format. Most of them are scripts instead
of binaries.</para> of binaries.</para>
<para>Take care <emphasis>not</emphasis> to use <para>Take care <emphasis>not</emphasis> to use
<emphasis>--strip-unneeded</emphasis> on the libraries -- they would be <emphasis>--strip-unneeded</emphasis> on the libraries -- the static ones
destroyed and you would have to build Glibc all over again.</para> would be destroyed and you would have to build the three toolchain packages
all over again.</para>
<para>To save another couple of megabytes, you can throw away all the <para>To save another couple of megabytes, you can throw away all the
documentation:</para> documentation:</para>

2
chapter05/gettext.xml
View File

@ -22,7 +22,7 @@
<screen><userinput>make</userinput></screen> <screen><userinput>make</userinput></screen>
<para>(If you insist on testing the results, then issue: <userinput>make <para>(If you insist on testing the results, then issue: <userinput>make
check</userinput>. This takes a very long time, around 6 SBUs. Moreover, the check</userinput>. This takes a very long time, around 7 SBUs. Moreover, the
Gettext test suite is known to experience failures under certain host Gettext test suite is known to experience failures under certain host
conditions -- for example when it finds a Java compiler on the host (but an conditions -- for example when it finds a Java compiler on the host (but an
experimental patch to disable Java is available from the LFS Patches experimental patch to disable Java is available from the LFS Patches

2
chapter06/gettext.xml
View File

@ -27,7 +27,7 @@ localization. These allow programs to be compiled with Native Language Support
<para>To have the results tested, issue: <para>To have the results tested, issue:
<userinput>make check</userinput>. This takes a very long time, around <userinput>make check</userinput>. This takes a very long time, around
6 SBUs.</para> 7 SBUs.</para>
<para>And install the package:</para> <para>And install the package:</para>

7
chapter06/patch.xml
View File

@ -15,13 +15,12 @@
<sect2> <sect2>
<title>Installation of Patch</title> <title>Installation of Patch</title>
<para>Prepare Patch for compilation:</para> <para>Prepare Patch for compilation (the preprocessor flag
<emphasis>-D_GNU_SOURCE</emphasis> is only needed on PowerPCs, on other
machines you can leave it out):</para>
<screen><userinput>CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/usr</userinput></screen> <screen><userinput>CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/usr</userinput></screen>
<para>Again, the preprocessor flag <emphasis>-D_GNU_SOURCE</emphasis> is only
needed on the PowerPC platform. On other architectures you can leave it out.</para>
<para>Compile the package:</para> <para>Compile the package:</para>
<screen><userinput>make</userinput></screen> <screen><userinput>make</userinput></screen>

2
entities/autoconf.ent
View File

@ -13,4 +13,4 @@
<!ENTITY autoconf-size "903 KB"> <!ENTITY autoconf-size "903 KB">
<!ENTITY autoconf-compsize "7.7 MB"> <!ENTITY autoconf-compsize "7.7 MB">
<!ENTITY autoconf-time "2.9 SBU"> <!ENTITY autoconf-time "0.5 SBU">

2
entities/automake.ent
View File

@ -13,4 +13,4 @@
<!ENTITY automake-size "623 KB"> <!ENTITY automake-size "623 KB">
<!ENTITY automake-compsize "6.8 MB"> <!ENTITY automake-compsize "6.8 MB">
<!ENTITY automake-time "5.3 SBU"> <!ENTITY automake-time "0.2 SBU">

4
entities/gettext.ent
View File

@ -15,7 +15,7 @@
<!ENTITY gettext-size "6,397 KB"> <!ENTITY gettext-size "6,397 KB">
<!ENTITY gettext-compsize-tools "55 MB"> <!ENTITY gettext-compsize-tools "55 MB">
<!ENTITY gettext-time-tools "7.2 SBU"> <!ENTITY gettext-time-tools "0.5 SBU">
<!ENTITY gettext-compsize "55 MB"> <!ENTITY gettext-compsize "55 MB">
<!ENTITY gettext-time "6.9 SBU"> <!ENTITY gettext-time "0.5 SBU">