mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-03-05 22:04:48 +00:00
Bring in DIY's next generation build method. Move GRUB to chapter 8.
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@8755 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Jeremy Huntwork
parent
6e886330cf
commit
4e82d4787a
@ -36,6 +36,21 @@
|
||||
</listitem>
|
||||
|
||||
-->
|
||||
<listitem>
|
||||
<para>2008-12-04</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>[jhuntwork] - Introduce new build method in Chapter 5 originating
|
||||
in DIY-Linux. Thanks, Greg Schafer.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>[jhuntwork] - Move instructions for GRUB to chapter 8 just after the
|
||||
compilation of the kernel. Merge GRUB build and configuration instructions
|
||||
into one page.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>2008-12-03</para>
|
||||
<itemizedlist>
|
||||
|
||||
@ -213,7 +213,7 @@
|
||||
<title>Added:</title>
|
||||
|
||||
<listitem>
|
||||
<para>None yet</para>
|
||||
<para>&gcc-startfiles-patch;</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
@ -114,6 +114,14 @@
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>GCC Startfiles Fix Patch - <token>&gcc-startfiles-patch-size;</token>:</term>
|
||||
<listitem>
|
||||
<para>Download: <ulink url="&patches-root;&gcc-startfiles-patch;"/></para>
|
||||
<para>MD5 sum: <literal>&gcc-startfiles-patch-md5;</literal></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Glibc Iconv Test Fixes Patch - <token>&glibc-iconv-test-fixes-patch-size;</token>:</term>
|
||||
<listitem>
|
||||
|
||||
@ -42,8 +42,9 @@ EOF</userinput></screen>
|
||||
umask 022
|
||||
LFS=/mnt/lfs
|
||||
LC_ALL=POSIX
|
||||
LFS_TGT=$(uname -m)-lfs-linux-gnu
|
||||
PATH=/tools/bin:/bin:/usr/bin
|
||||
export LFS LC_ALL PATH</literal>
|
||||
export LFS LC_ALL LFS_TGT PATH</literal>
|
||||
EOF</userinput></screen>
|
||||
|
||||
<para>The <command>set +h</command> command turns off
|
||||
@ -76,6 +77,11 @@ EOF</userinput></screen>
|
||||
<quote>POSIX</quote> or <quote>C</quote> (the two are equivalent) ensures that
|
||||
everything will work as expected in the chroot environment.</para>
|
||||
|
||||
<para>The <envar>LFS_TGT</envar> variable sets a non-default, but compatible machine
|
||||
description for use when building our cross compiler and linker and when cross
|
||||
compiling our temporary toolchain. More information is contained in
|
||||
<xref linkend="ch-tools-toolchaintechnotes" role=""/>.</para>
|
||||
|
||||
<para>By putting <filename class="directory">/tools/bin</filename> ahead of the
|
||||
standard <envar>PATH</envar>, all the programs installed in <xref
|
||||
linkend="chapter-temporary-tools"/> are picked up by the shell immediately after
|
||||
|
||||
@ -12,26 +12,13 @@
|
||||
|
||||
<para>Now that the temporary C libraries have been installed, all
|
||||
tools compiled in the rest of this chapter should be linked against
|
||||
these libraries. In order to accomplish this, the linker and the
|
||||
compiler's specs file need to be adjusted.</para>
|
||||
these libraries. In order to accomplish this, the cross-compiler's
|
||||
specs file needs to be adjusted to point to the new dynamic linker
|
||||
in <filename class="directory">/tools</filename>.</para>
|
||||
|
||||
<para>The linker, adjusted at the end of the first pass of Binutils, needs
|
||||
to be renamed so that it can be properly found and used. First, backup the
|
||||
original linker, then replace it with the adjusted linker. We'll also
|
||||
create a link to its counterpart in <filename class="directory">
|
||||
/tools/$(gcc -dumpmachine)/bin</filename>:</para>
|
||||
|
||||
<screen><userinput>mv -v /tools/bin/{ld,ld-old}
|
||||
mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
|
||||
mv -v /tools/bin/{ld-new,ld}
|
||||
ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld</userinput></screen>
|
||||
|
||||
<para>From this point onwards, everything will link only against the
|
||||
libraries in <filename class="directory">/tools/lib</filename>.</para>
|
||||
|
||||
<para>The next task is to point GCC to the new dynamic linker. This is done by
|
||||
dumping GCC's <quote>specs</quote> file to a location where GCC will look for it
|
||||
by default. A simple <command>sed</command> substitution then alters the
|
||||
<para>This is done by dumping the compiler's <quote>specs</quote> file to a
|
||||
location where it will look for it by default.
|
||||
A simple <command>sed</command> substitution then alters the
|
||||
dynamic linker that GCC will use. The principle here is to find all references
|
||||
to the dynamic linker file in <filename class="directory">/lib</filename>
|
||||
or possibly <filename class="directory">/lib64</filename> if the host system
|
||||
@ -46,28 +33,12 @@ ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld</userinput></screen>
|
||||
of the dynamic linker, if necessary.</para>
|
||||
|
||||
<!-- Ampersands are needed to allow copy and paste -->
|
||||
<screen><userinput>gcc -dumpspecs | sed 's@/lib\(64\)\?/ld@/tools&@g' > \
|
||||
`dirname $(gcc -print-libgcc-file-name)`/specs</userinput></screen>
|
||||
|
||||
<para>During the build process, GCC runs a script
|
||||
(<command>fixincludes</command>) that scans the system for header files
|
||||
that may need to be fixed (they might contain syntax errors, for example),
|
||||
and installs the fixed versions in a private include directory. There is a
|
||||
possibility that, as a result of this process, some header files from the
|
||||
host system have found their way into GCC's private include directory. As
|
||||
the rest of this chapter only requires the headers from GCC and Glibc,
|
||||
which have both been installed at this point, any <quote>fixed</quote>
|
||||
headers can safely be removed. This helps to avoid any host headers
|
||||
polluting the build environment. Run the following commands to remove the
|
||||
header files in GCC's private include directory (you may find it easier to
|
||||
copy and paste these commands, rather than typing them by hand, due to
|
||||
their length):</para>
|
||||
|
||||
<!-- && used to ease copy and pasting -->
|
||||
<screen><userinput>GCC_FIXED=`dirname $(gcc -print-libgcc-file-name)`/include-fixed &&
|
||||
find ${GCC_FIXED}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \; &&
|
||||
rm -vf `grep -l "DO NOT EDIT THIS FILE" ${GCC_FIXED}/*` &&
|
||||
unset GCC_FIXED</userinput></screen>
|
||||
<screen><userinput>SPECS=`dirname $($LFS_TGT-gcc -print-libgcc-file-name)`/specs
|
||||
$LFS_TGT-gcc -dumpspecs | sed \
|
||||
-e 's@/lib\(64\)\?/ld@/tools&@g' \
|
||||
-e "/^\*cpp:$/{n;s,$, -isystem /tools/include,}" > $SPECS
|
||||
echo "New specs file is: $SPECS"
|
||||
unset SPECS</userinput></screen>
|
||||
|
||||
<caution>
|
||||
<para>At this point, it is imperative to stop and ensure that the basic
|
||||
@ -75,7 +46,7 @@ unset GCC_FIXED</userinput></screen>
|
||||
expected. To perform a sanity check, run the following commands:</para>
|
||||
|
||||
<screen><userinput>echo 'main(){}' > dummy.c
|
||||
cc dummy.c
|
||||
$LFS_TGT-gcc -B/tools/lib dummy.c
|
||||
readelf -l a.out | grep ': /tools'</userinput></screen>
|
||||
|
||||
<para>If everything is working correctly, there should be no errors,
|
||||
@ -91,17 +62,7 @@ readelf -l a.out | grep ': /tools'</userinput></screen>
|
||||
<para>If the output is not shown as above or there was no output at all,
|
||||
then something is wrong. Investigate and retrace the steps to find out
|
||||
where the problem is and correct it. This issue must be resolved before
|
||||
continuing on. First, perform the sanity check again, using
|
||||
<command>gcc</command> instead of <command>cc</command>. If this works,
|
||||
then the <filename class="symlink">/tools/bin/cc</filename> symlink is
|
||||
missing. Revisit <xref linkend="ch-tools-gcc-pass1" role=","/> and install
|
||||
the symlink. Next, ensure that the <envar>PATH</envar> is correct. This
|
||||
can be checked by running <command>echo $PATH</command> and verifying that
|
||||
<filename class="directory">/tools/bin</filename> is at the head of the
|
||||
list. If the <envar>PATH</envar> is wrong it could mean that you are not
|
||||
logged in as user <systemitem class="username">lfs</systemitem> or that
|
||||
something went wrong back in <xref linkend="ch-tools-settingenviron"
|
||||
role="."/> Another option is that something may have gone wrong with the
|
||||
continuing on. Something may have gone wrong with the
|
||||
specs file amendment above. In this case, redo the specs file amendment,
|
||||
being careful to copy-and-paste the commands.</para>
|
||||
|
||||
@ -111,9 +72,9 @@ readelf -l a.out | grep ': /tools'</userinput></screen>
|
||||
|
||||
</caution>
|
||||
|
||||
<note><para>Building Tcl in the next section will serve as an additional check that
|
||||
the toolchain has been built properly. If Tcl fails to build, it is an
|
||||
indication that something has gone wrong with the Binutils, GCC, or Glibc
|
||||
installation, but not with Tcl itself.</para></note>
|
||||
<note><para>Building Binutils in the next section will serve as an additional check that
|
||||
the toolchain has been built properly. If Binutils fails to build, it is an
|
||||
indication that something has gone wrong with the previous Binutils, GCC, or Glibc
|
||||
installations.</para></note>
|
||||
|
||||
</sect1>
|
||||
|
||||
@ -41,7 +41,7 @@
|
||||
</sect2>
|
||||
|
||||
<sect2 role="installation">
|
||||
<title>Installation of Binutils</title>
|
||||
<title>Installation of Cross Binutils</title>
|
||||
|
||||
<para>It is important that Binutils be the first package compiled
|
||||
because both Glibc and GCC perform various tests on the available
|
||||
@ -70,19 +70,20 @@ cd ../binutils-build</userinput></screen>
|
||||
|
||||
<para>Now prepare Binutils for compilation:</para>
|
||||
|
||||
<screen><userinput remap="configure">CC="gcc -B/usr/bin/" ../binutils-&binutils-version;/configure \
|
||||
--prefix=/tools --disable-nls --disable-werror</userinput></screen>
|
||||
<screen><userinput remap="configure">../binutils-&binutils-version;/configure \
|
||||
--target=$LFS_TGT --prefix=/tools \
|
||||
--disable-nls --disable-werror</userinput></screen>
|
||||
|
||||
<variablelist>
|
||||
<title>The meaning of the configure options:</title>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>CC="gcc -B/usr/bin/"</envar></term>
|
||||
<term><envar>--target=$LFS_TGT</envar></term>
|
||||
<listitem>
|
||||
<para>This forces <command>gcc</command> to prefer the linker from
|
||||
the host in <filename class="directory">/usr/bin</filename>. This
|
||||
is necessary on some hosts where the new <command>ld</command>
|
||||
built here is not compatible with the host's <command>gcc</command>.
|
||||
<para>Because the machine description in the <envar>LFS_TGT</envar>
|
||||
variable is slightly different than the value returned by the
|
||||
config.guess script, this switch will tell the configure script to
|
||||
adjust Binutil's build system for building a cross linker.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -124,49 +125,17 @@ cd ../binutils-build</userinput></screen>
|
||||
tests at this point are minimal since the programs from this
|
||||
first pass will soon be replaced by those from the second.</para>
|
||||
|
||||
<para>Create a symlink to ensure the sanity of our toolchain:</para>
|
||||
<para>If building on x86_64, create a symlink to ensure the sanity of
|
||||
the toolchain:</para>
|
||||
|
||||
<screen><userinput remap="install">mkdir -v /tools/lib
|
||||
ln -sv lib /tools/lib64</userinput></screen>
|
||||
<screen><userinput remap="install">case $(uname -m) in
|
||||
x86_64) mkdir -v /tools/lib && ln -sv lib /tools/lib64 ;;
|
||||
esac</userinput></screen>
|
||||
|
||||
<para>Install the package:</para>
|
||||
|
||||
<screen><userinput remap="install">make install</userinput></screen>
|
||||
|
||||
<para>Finally, prepare the linker for the <quote>Adjusting</quote> phase
|
||||
later on:</para>
|
||||
|
||||
<screen><userinput remap="adjust">make -C ld clean
|
||||
make -C ld LIB_PATH=/tools/lib
|
||||
cp -v ld/ld-new /tools/bin</userinput></screen>
|
||||
|
||||
<variablelist>
|
||||
<title>The meaning of the make parameters:</title>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>-C ld clean</parameter></term>
|
||||
<listitem>
|
||||
<para>This tells the make program to remove all compiled
|
||||
files in the <filename class="directory">ld</filename>
|
||||
subdirectory.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>-C ld LIB_PATH=/tools/lib</parameter></term>
|
||||
<listitem>
|
||||
<para>This option rebuilds everything in the <filename
|
||||
class="directory">ld</filename> subdirectory. Specifying the
|
||||
<envar>LIB_PATH</envar> Makefile variable on the command line
|
||||
allows us to override the default value and point it to the
|
||||
temporary tools location. The value of this variable specifies
|
||||
the linker's default library search path. This preparation is
|
||||
used later in the chapter.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="content">
|
||||
|
||||
@ -41,7 +41,7 @@
|
||||
</sect2>
|
||||
|
||||
<sect2 role="installation">
|
||||
<title>Re-installation of Binutils</title>
|
||||
<title>Installation of Binutils</title>
|
||||
|
||||
<para>Binutils does not recognize versions of Texinfo newer than 4.9. Fix
|
||||
this issue by applying the following patch:</para>
|
||||
@ -55,12 +55,23 @@ cd ../binutils-build</userinput></screen>
|
||||
|
||||
<para>Prepare Binutils for compilation:</para>
|
||||
|
||||
<screen><userinput remap="configure">../binutils-&binutils-version;/configure --prefix=/tools \
|
||||
--disable-nls --with-lib-path=/tools/lib</userinput></screen>
|
||||
<screen><userinput remap="configure">CC="$LFS_TGT-gcc -B/tools/lib/" \
|
||||
AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib \
|
||||
../binutils-&binutils-version;/configure --prefix=/tools \
|
||||
--disable-nls --with-lib-path=/tools/lib</userinput></screen>
|
||||
|
||||
<variablelist>
|
||||
<title>The meaning of the new configure options:</title>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>CC="$LFS_TGT-gcc -B/tools/lib/" AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib</parameter></term>
|
||||
<listitem>
|
||||
<para>Because this is really a native build of Binutils, setting these
|
||||
variables ensures that the build system uses the cross-compiler and
|
||||
associated tools instead of the ones on the host system.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--with-lib-path=/tools/lib</parameter></term>
|
||||
<listitem>
|
||||
@ -78,13 +89,6 @@ cd ../binutils-build</userinput></screen>
|
||||
|
||||
<screen><userinput remap="make">make</userinput></screen>
|
||||
|
||||
<para>Compilation is now complete. As discussed earlier, running the
|
||||
test suite is not mandatory for the temporary tools here in this
|
||||
chapter. To run the Binutils test suite anyway, issue the following
|
||||
command:</para>
|
||||
|
||||
<screen><userinput remap="test">make check</userinput></screen>
|
||||
|
||||
<para>Install the package:</para>
|
||||
|
||||
<screen><userinput remap="install">make install</userinput></screen>
|
||||
@ -96,6 +100,33 @@ cd ../binutils-build</userinput></screen>
|
||||
make -C ld LIB_PATH=/usr/lib:/lib
|
||||
cp -v ld/ld-new /tools/bin</userinput></screen>
|
||||
|
||||
<variablelist>
|
||||
<title>The meaning of the make parameters:</title>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>-C ld clean</parameter></term>
|
||||
<listitem>
|
||||
<para>This tells the make program to remove all compiled
|
||||
files in the <filename class="directory">ld</filename>
|
||||
subdirectory.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>-C ld LIB_PATH=/usr/lib:/lib</parameter></term>
|
||||
<listitem>
|
||||
<para>This option rebuilds everything in the <filename
|
||||
class="directory">ld</filename> subdirectory. Specifying the
|
||||
<envar>LIB_PATH</envar> Makefile variable on the command line
|
||||
allows us to override the default value of the temporary tools
|
||||
and point it to the proper final path. The value of this variable
|
||||
specifies the linker's default library search path. This
|
||||
preparation is used in the next chapter.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="content">
|
||||
|
||||
@ -19,13 +19,11 @@
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="linux-headers.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="glibc.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="adjusting.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="binutils-pass2.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="gcc-pass2.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="tcl.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="expect.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="dejagnu.xml"/>
|
||||
<!-- <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="gmp.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="mpfr.xml"/> -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="gcc-pass2.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="binutils-pass2.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="ncurses.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="bash.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="bzip2.xml"/>
|
||||
|
||||
@ -41,7 +41,7 @@
|
||||
</sect2>
|
||||
|
||||
<sect2 role="installation">
|
||||
<title>Installation of GCC</title>
|
||||
<title>Installation of Cross GCC</title>
|
||||
|
||||
<para>GCC now requires the GMP and MPFR packages. As these packages may
|
||||
not be included in your host distribution, they will be built with
|
||||
@ -60,35 +60,16 @@ cd ../gcc-build</userinput></screen>
|
||||
|
||||
<para>Prepare GCC for compilation:</para>
|
||||
|
||||
<screen><userinput remap="configure">CC="gcc -B/usr/bin/" ../gcc-&gcc-version;/configure --prefix=/tools \
|
||||
--with-local-prefix=/tools --disable-nls --disable-shared --disable-libssp \
|
||||
--disable-multilib --enable-languages=c</userinput></screen>
|
||||
<screen><userinput remap="configure">../gcc-&gcc-version;/configure \
|
||||
--target=$LFS_TGT --prefix=/tools \
|
||||
--disable-nls --disable-shared --disable-multilib \
|
||||
--disable-decimal-float --disable-threads \
|
||||
--disable-libmudflap --disable-libssp \
|
||||
--disable-libgomp --enable-languages=c</userinput></screen>
|
||||
|
||||
<variablelist>
|
||||
<title>The meaning of the configure options:</title>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>CC="gcc -B/usr/bin/"</envar></term>
|
||||
<listitem>
|
||||
<para>This forces <command>gcc</command> to prefer the linker from
|
||||
the host in <filename class="directory">/usr/bin</filename>. This
|
||||
is necessary on some hosts where the new <command>ld</command>
|
||||
built in the previous section is not compatible with the host's
|
||||
<command>gcc</command>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--with-local-prefix=/tools</parameter></term>
|
||||
<listitem>
|
||||
<para>The purpose of this switch is to remove <filename
|
||||
class="directory">/usr/local/include</filename> from
|
||||
<command>gcc</command>'s include search path. This is not
|
||||
absolutely essential, however, it helps to minimize the
|
||||
influence of the host system.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--disable-shared</parameter></term>
|
||||
<listitem>
|
||||
@ -99,10 +80,20 @@ cd ../gcc-build</userinput></screen>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--disable-libssp</parameter></term>
|
||||
<term><parameter>--disable-decimal-float, --disable-threads, --disable-libmudflap, --disable-libssp, --disable-libgomp</parameter></term>
|
||||
<listitem>
|
||||
<para>This switch prevents a conflict with older versions of
|
||||
glibc which can cause the build to fail.</para>
|
||||
<para>These switches disable support for the decimal floating point extension,
|
||||
threading, libmudflap, libssp and libgomp respectively. These features will fail
|
||||
to compile when building a cross-compiler and are not necessary for the task of
|
||||
cross-compiling the temporary libc.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--disable-multilib</parameter></term>
|
||||
<listitem>
|
||||
<para>On x86_64, LFS does not yet support a multilib configuration.
|
||||
This switch is harmless for x86.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -114,22 +105,9 @@ cd ../gcc-build</userinput></screen>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--disable-multilib</parameter></term>
|
||||
<listitem>
|
||||
<para>We currently only want to build support for 64-bit libraries.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
<para>The following command will compile GCC not once, but several times. It
|
||||
uses the programs compiled in a first round to compile itself a second time,
|
||||
and then again a third time. It then compares these second and third compiles
|
||||
to make sure it can reproduce itself flawlessly. This is called
|
||||
<quote>bootstrapping</quote>. Building GCC in this way ensures that it was
|
||||
compiled correctly and is now the default configuration for the released
|
||||
package. Continue with compiling by running:</para>
|
||||
<para>Compile GCC by running:</para>
|
||||
|
||||
<screen><userinput remap="make">make</userinput></screen>
|
||||
|
||||
@ -146,23 +124,14 @@ cd ../gcc-build</userinput></screen>
|
||||
<para>Using <parameter>--disable-shared</parameter> means that the
|
||||
<filename>libgcc_eh.a</filename> file isn't created and installed. The
|
||||
Glibc package depends on this library as it uses
|
||||
<parameter>-lgcc_eh</parameter> within its build system. We can satisfy
|
||||
that dependency by creating a symlink to <filename>libgcc.a</filename>,
|
||||
<parameter>-lgcc_eh</parameter> within its build system. This dependency
|
||||
can be satisfied by creating a symlink to <filename>libgcc.a</filename>,
|
||||
since that file will end up containing the objects normally contained in
|
||||
<filename>libgcc_eh.a</filename>.</para>
|
||||
|
||||
<screen><userinput remap="install">ln -vs libgcc.a `gcc -print-libgcc-file-name | \
|
||||
<screen><userinput remap="install">ln -vs libgcc.a `$LFS_TGT-gcc -print-libgcc-file-name | \
|
||||
sed 's/libgcc/&_eh/'`</userinput></screen>
|
||||
|
||||
<para>As a finishing touch, create a symlink. Many programs and scripts
|
||||
run <command>cc</command> instead of <command>gcc</command>, which is
|
||||
used to keep programs generic and therefore usable on all kinds of UNIX
|
||||
systems where the GNU C compiler is not always installed. Running
|
||||
<command>cc</command> leaves the system administrator free to decide
|
||||
which C compiler to install:</para>
|
||||
|
||||
<screen><userinput remap="install">ln -vs gcc /tools/bin/cc</userinput></screen>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="content">
|
||||
|
||||
@ -41,33 +41,19 @@
|
||||
</sect2>
|
||||
|
||||
<sect2 role="installation">
|
||||
<title>Re-installation of GCC</title>
|
||||
<title>Installation of GCC</title>
|
||||
|
||||
<para>The tools required to test GCC and Binutils—Tcl, Expect
|
||||
and DejaGNU—are installed now. GCC and Binutils can now be
|
||||
rebuilt, linking them against the new Glibc and testing them properly
|
||||
(if running the test suites in this chapter). Please note that these
|
||||
test suites are highly dependent on properly functioning PTYs which
|
||||
are provided by the host. PTYs are most commonly implemented via the
|
||||
<systemitem class="filesystem">devpts</systemitem> file system. Check
|
||||
to see if the host system is set up correctly in this regard by
|
||||
performing a quick test:</para>
|
||||
<para>Versions of GCC later than 4.3 will treat this build as if
|
||||
it were a relocated compiler and disallow searching for startfiles in
|
||||
the location specified by <parameter>--prefix</parameter>. Since this
|
||||
will not be a relocated compiler, and the startfiles in
|
||||
<filename class="directory">/tools</filename> are crucial to building
|
||||
a working compiler linked to the libs in <filename class="directory">/tools</filename>,
|
||||
apply the following patch which partially reverts GCC to its old behavior:</para>
|
||||
|
||||
<screen><userinput remap="test">expect -c "spawn ls"</userinput></screen>
|
||||
<screen><userinput remap="pre">patch -Np1 -i ../&gcc-startfiles-patch;</userinput></screen>
|
||||
|
||||
<para>The response might be:</para>
|
||||
|
||||
<screen><computeroutput>The system has no more ptys.
|
||||
Ask your system administrator to create more.</computeroutput></screen>
|
||||
|
||||
<para>If the above message is received, the host does not have its PTYs
|
||||
set up properly. In this case, there is no point in running the test
|
||||
suites for GCC and Binutils until this issue is resolved. Please consult
|
||||
the LFS FAQ at <ulink url="&lfs-root;/lfs/faq.html#no-ptys"/> for more
|
||||
information on how to get PTYs working.</para>
|
||||
|
||||
<para>As previously explained in <xref linkend="ch-tools-adjusting"/>,
|
||||
under normal circumstances the GCC <command>fixincludes</command> script
|
||||
<para>Under normal circumstances the GCC <command>fixincludes</command> script
|
||||
is run in order to fix potentially broken header files. As GCC-&gcc-version;
|
||||
and Glibc-&glibc-version; have already been installed at this point, and
|
||||
their respective header files are known to not require fixing, the
|
||||
@ -80,18 +66,17 @@ Ask your system administrator to create more.</computeroutput></screen>
|
||||
<screen><userinput remap="pre">cp -v gcc/Makefile.in{,.orig}
|
||||
sed 's@\./fixinc\.sh@-c true@' gcc/Makefile.in.orig > gcc/Makefile.in</userinput></screen>
|
||||
|
||||
<para>The bootstrap build performed in <xref linkend="ch-tools-gcc-pass1"/>
|
||||
built GCC with the <option>-fomit-frame-pointer</option> compiler flag.
|
||||
Non-bootstrap builds omit this flag by default, so apply the following
|
||||
<command>sed</command> to use it in order to ensure consistent compiler
|
||||
builds:</para>
|
||||
<para>Non-bootstrap builds omit the <option>-fomit-frame-pointer</option>
|
||||
build flag by default, and the goal should be to produce a compiler that is
|
||||
exactly the same as if it were bootstrapped. Apply the following
|
||||
<command>sed</command> command to force the build to use the flag:</para>
|
||||
|
||||
<screen><userinput remap="pre">cp -v gcc/Makefile.in{,.tmp}
|
||||
sed 's/^XCFLAGS =$/& -fomit-frame-pointer/' gcc/Makefile.in.tmp \
|
||||
> gcc/Makefile.in</userinput></screen>
|
||||
|
||||
<para>The following command will change the location of GCC's default
|
||||
dynamic linker to use the one we installed in
|
||||
dynamic linker to use the one installed in
|
||||
<filename class="directory">/tools</filename>. It also removes <filename
|
||||
class="directory">/usr/include</filename> from GCC's include search path.
|
||||
Doing this now rather than adjusting the specs file after installation
|
||||
@ -105,9 +90,11 @@ do
|
||||
cp -uv $file{,.orig}
|
||||
sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&@g' \
|
||||
-e 's@/usr@/tools@g' $file.orig > $file
|
||||
echo "
|
||||
echo '
|
||||
#undef STANDARD_INCLUDE_DIR
|
||||
#define STANDARD_INCLUDE_DIR 0" >> $file
|
||||
#define STANDARD_INCLUDE_DIR 0
|
||||
#define STANDARD_STARTFILE_PREFIX_1 ""
|
||||
#define STANDARD_STARTFILE_PREFIX_2 ""' >> $file
|
||||
touch $file.orig
|
||||
done</userinput></screen>
|
||||
|
||||
@ -120,19 +107,24 @@ done</userinput></screen>
|
||||
<quote>/tools</quote> to every instance of <quote>/lib/ld</quote>,
|
||||
<quote>/lib64/ld</quote> or <quote>/lib32/ld</quote>, while the second one
|
||||
replaces hard-coded instances of <quote>/usr</quote>. Then we add our define
|
||||
statements which alter the include search path to the end of the file. Finally,
|
||||
we use <command>touch</command> to update the timestamp on the copied files.
|
||||
statements which alter the include search path and the default startfile prefix
|
||||
to the end of the file.
|
||||
Finally, we use <command>touch</command> to update the timestamp on the copied files.
|
||||
When used in conjunction with <command>cp -u</command>, this prevents unexpected
|
||||
changes to the original files in case the command is inadvertently run twice.
|
||||
</para>
|
||||
|
||||
<para>Unsetting the multlib spec for GCC ensures that it
|
||||
<para>On x86_64, unsetting the multlib spec for GCC ensures that it
|
||||
won't attempt to link against libraries on the host:</para>
|
||||
|
||||
<screen><userinput remap="pre">for file in $(find gcc/config -name t-linux64) ; do \
|
||||
cp -v $file{,.orig}
|
||||
sed '/MULTILIB_OSDIRNAMES/d' $file.orig > $file
|
||||
done</userinput></screen>
|
||||
<screen><userinput remap="pre">case $(uname -m) in
|
||||
x86_64)
|
||||
for file in $(find gcc/config -name t-linux64) ; do \
|
||||
cp -v $file{,.orig}
|
||||
sed '/MULTILIB_OSDIRNAMES/d' $file.orig > $file
|
||||
done
|
||||
;;
|
||||
esac</userinput></screen>
|
||||
|
||||
<para>As in the first build of GCC it requires the GMP and MPFR packages.
|
||||
Unpack the tarballs and move them into the required directory names:</para>
|
||||
@ -152,7 +144,9 @@ cd ../gcc-build</userinput></screen>
|
||||
|
||||
<para>Now prepare GCC for compilation:</para>
|
||||
|
||||
<screen><userinput remap="configure">../gcc-&gcc-version;/configure --prefix=/tools \
|
||||
<screen><userinput remap="configure">CC="$LFS_TGT-gcc -B/tools/lib/" \
|
||||
AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib \
|
||||
../gcc-&gcc-version;/configure --prefix=/tools \
|
||||
--with-local-prefix=/tools --enable-clocale=gnu \
|
||||
--enable-shared --enable-threads=posix \
|
||||
--enable-__cxa_atexit --enable-languages=c,c++ \
|
||||
@ -227,27 +221,58 @@ cd ../gcc-build</userinput></screen>
|
||||
|
||||
<screen><userinput remap="make">make</userinput></screen>
|
||||
|
||||
<para>Compilation is now complete. As previously mentioned, running the test
|
||||
suites for the temporary tools compiled in this chapter is not mandatory.
|
||||
To run the GCC test suite anyway, use the following command:</para>
|
||||
|
||||
<screen><userinput remap="test">make -k check</userinput></screen>
|
||||
|
||||
<para>The <parameter>-k</parameter> flag is used to make the test suite run
|
||||
through to completion and not stop at the first failure. The GCC test
|
||||
suite is very comprehensive and is almost guaranteed to generate a few
|
||||
failures.</para>
|
||||
|
||||
<para>For a discussion of test failures that are of particular
|
||||
importance, please see <xref linkend="ch-system-gcc" role="."/></para>
|
||||
|
||||
<para>Install the package:</para>
|
||||
|
||||
<screen><userinput remap="install">make install</userinput></screen>
|
||||
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
|
||||
href="adjusting.xml"
|
||||
xpointer="xpointer(/sect1/caution[1])"/>
|
||||
<para>As a finishing touch, create a symlink. Many programs and scripts
|
||||
run <command>cc</command> instead of <command>gcc</command>, which is
|
||||
used to keep programs generic and therefore usable on all kinds of UNIX
|
||||
systems where the GNU C compiler is not always installed. Running
|
||||
<command>cc</command> leaves the system administrator free to decide
|
||||
which C compiler to install:</para>
|
||||
|
||||
<screen><userinput remap="install">ln -vs gcc /tools/bin/cc</userinput></screen>
|
||||
|
||||
<caution>
|
||||
<para>At this point, it is imperative to stop and ensure that the basic
|
||||
functions (compiling and linking) of the new toolchain are working as
|
||||
expected. To perform a sanity check, run the following commands:</para>
|
||||
|
||||
<screen><userinput>echo 'main(){}' > dummy.c
|
||||
cc dummy.c
|
||||
readelf -l a.out | grep ': /tools'</userinput></screen>
|
||||
|
||||
<para>If everything is working correctly, there should be no errors,
|
||||
and the output of the last command will be of the form:</para>
|
||||
|
||||
<screen><computeroutput>[Requesting program interpreter:
|
||||
/tools/lib/ld-linux.so.2]</computeroutput></screen>
|
||||
|
||||
<para>Note that <filename class="directory">/tools/lib</filename>, or
|
||||
<filename class="directory">/tools/lib64</filename> for 64-bit machines
|
||||
appears as the prefix of the dynamic linker.</para>
|
||||
|
||||
<para>If the output is not shown as above or there was no output at all,
|
||||
then something is wrong. Investigate and retrace the steps to find out
|
||||
where the problem is and correct it. This issue must be resolved before
|
||||
continuing on. First, perform the sanity check again, using
|
||||
<command>gcc</command> instead of <command>cc</command>. If this works,
|
||||
then the <filename class="symlink">/tools/bin/cc</filename> symlink is
|
||||
missing. Install the symlink as per above.
|
||||
Next, ensure that the <envar>PATH</envar> is correct. This
|
||||
can be checked by running <command>echo $PATH</command> and verifying that
|
||||
<filename class="directory">/tools/bin</filename> is at the head of the
|
||||
list. If the <envar>PATH</envar> is wrong it could mean that you are not
|
||||
logged in as user <systemitem class="username">lfs</systemitem> or that
|
||||
something went wrong back in <xref linkend="ch-tools-settingenviron"
|
||||
role="."/></para>
|
||||
|
||||
<para>Once all is well, clean up the test files:</para>
|
||||
|
||||
<screen><userinput>rm -v dummy.c a.out</userinput></screen>
|
||||
|
||||
</caution>
|
||||
|
||||
</sect2>
|
||||
|
||||
|
||||
@ -43,11 +43,6 @@
|
||||
<sect2 role="installation">
|
||||
<title>Installation of Glibc</title>
|
||||
|
||||
<para>Fix a potential issue if <filename>/etc/ld.so.preload</filename> is
|
||||
used on the host system.</para>
|
||||
|
||||
<screen><userinput remap="pre">sed -i 's@/etc/ld.so.preload@/tools/etc/ld.so.preload@' elf/rtld.c</userinput></screen>
|
||||
|
||||
<para>The Glibc documentation recommends building Glibc outside of the source
|
||||
directory in a dedicated build directory:</para>
|
||||
|
||||
@ -71,14 +66,23 @@ esac</userinput></screen>
|
||||
<para>Next, prepare Glibc for compilation:</para>
|
||||
|
||||
<screen><userinput remap="configure">../glibc-&glibc-version;/configure --prefix=/tools \
|
||||
--host=$LFS_TGT --build=$(../glibc-&glibc-version;/scripts/config.guess) \
|
||||
--disable-profile --enable-add-ons \
|
||||
--enable-kernel=2.6.0 --with-binutils=/tools/bin \
|
||||
--without-gd --with-headers=/tools/include \
|
||||
--without-selinux</userinput></screen>
|
||||
--enable-kernel=2.6.0 --with-headers=/tools/include \
|
||||
libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes</userinput></screen>
|
||||
|
||||
<variablelist>
|
||||
<title>The meaning of the configure options:</title>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--host=$LFS_TGT, --build=$(../glibc-&glibc-version;/scripts/config.guess)</parameter></term>
|
||||
<listitem>
|
||||
<para>The combined effect of these switches is that Glibc's build system
|
||||
configures itself to cross-compile, using the cross-linker and
|
||||
cross-compiler in <filename class="directory">/tools</filename>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--disable-profile</parameter></term>
|
||||
<listitem>
|
||||
@ -103,24 +107,6 @@ esac</userinput></screen>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--with-binutils=/tools/bin</parameter></term>
|
||||
<listitem>
|
||||
<para>While not required, this switch ensures that there are
|
||||
no errors pertaining to which Binutils programs get used during the
|
||||
Glibc build.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--without-gd</parameter></term>
|
||||
<listitem>
|
||||
<para>This prevents the build of the <command>memusagestat</command>
|
||||
program, which insists on linking against the host's libraries
|
||||
(libgd, libpng, libz, etc.).</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--with-headers=/tools/include</parameter></term>
|
||||
<listitem>
|
||||
@ -131,12 +117,19 @@ esac</userinput></screen>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--without-selinux</parameter></term>
|
||||
<term><parameter>libc_cv_forced_unwind=yes</parameter></term>
|
||||
<listitem>
|
||||
<para>When building from hosts that include SELinux functionality
|
||||
(e.g., Fedora Core 3), Glibc will build with support for SELinux.
|
||||
As the LFS tools environment does not contain support for SELinux, a
|
||||
Glibc compiled with such support will fail to operate correctly.</para>
|
||||
<para>The build requires support for forced unwind, but because it is
|
||||
being cross compiled, it cannot auto detect it. Setting this variable
|
||||
on the command line explicitly tells the configure script that support
|
||||
is available.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>libc_cv_c_cleanup=yes</parameter></term>
|
||||
<listitem>
|
||||
<para>The build also requires support for C cleanup handling, which it
|
||||
cannot auto detect when being cross compiled. Enable it explicitly.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -167,13 +160,6 @@ esac</userinput></screen>
|
||||
<para>This package does come with a test suite, however, it cannot be
|
||||
run at this time because we do not have a C++ compiler yet.</para>
|
||||
|
||||
<para>The install stage of Glibc will issue a harmless warning at the
|
||||
end about the absence of <filename>/tools/etc/ld.so.conf</filename>.
|
||||
Prevent this warning with:</para>
|
||||
|
||||
<screen><userinput remap="install">mkdir -v /tools/etc
|
||||
touch /tools/etc/ld.so.conf</userinput></screen>
|
||||
|
||||
<para>Install the package:</para>
|
||||
|
||||
<screen><userinput remap="install">make install</userinput></screen>
|
||||
|
||||
@ -14,7 +14,7 @@
|
||||
behind the overall build method. It is not essential to immediately
|
||||
understand everything in this section. Most of this information will be
|
||||
clearer after performing an actual build. This section can be referred
|
||||
back to at any time during the process.</para>
|
||||
to at any time during the process.</para>
|
||||
|
||||
<para>The overall goal of <xref linkend="chapter-temporary-tools"/> is to
|
||||
provide a temporary environment that can be chrooted into and from which can be
|
||||
@ -54,13 +54,17 @@
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>The process is similar in principle to cross-compiling, whereby
|
||||
tools installed in the same prefix work in cooperation, and thus utilize
|
||||
a little GNU <quote>magic</quote></para>
|
||||
<para>Slightly adjusting the name of the working platform ensures that
|
||||
the first build of Binutils and GCC produces a compatible cross-linker
|
||||
and cross-compiler. Instead of producing binaries for another architecture,
|
||||
the cross-linker and cross-compiler will produce binaries compatible with
|
||||
the current hardware.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Careful manipulation of the standard linker's library search path
|
||||
ensures programs are linked only against chosen libraries</para>
|
||||
<para>The temporary libraries are cross-compiled. This removes all
|
||||
dependency on the host system, lessens the chance of headers or libraries
|
||||
from the host corrupting the new tools and allows for the possibility of
|
||||
building both 32-bit and 64-bit libraries on 64-bit capable hardware.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Careful manipulation of <command>gcc</command>'s
|
||||
|
||||
@ -48,7 +48,6 @@
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="gawk.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="findutils.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="flex.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="grub.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="gettext.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="groff.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="gzip.xml"/>
|
||||
|
||||
@ -24,8 +24,9 @@ mkdir -pv /usr/{,local/}share/man/man{1..8}
|
||||
for dir in /usr /usr/local; do
|
||||
ln -sv share/{man,doc,info} $dir
|
||||
done
|
||||
ln -sv lib /lib64
|
||||
ln -sv lib /usr/lib64
|
||||
case $(uname -m) in
|
||||
x86_64) ln -sv lib /lib64 && ln -sv lib /usr/lib64 ;;
|
||||
esac
|
||||
mkdir -v /var/{lock,log,mail,run,spool}
|
||||
mkdir -pv /var/{opt,cache,lib/{misc,locate},local}</userinput></screen>
|
||||
|
||||
|
||||
@ -33,9 +33,10 @@ mv -v /tools/bin/{ld-new,ld}
|
||||
ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld</userinput></screen>
|
||||
|
||||
<para>Next, amend the GCC specs file so that it points to the new
|
||||
dynamic linker, and so that GCC knows where to find the correct headers
|
||||
and Glibc start files. A <command>sed</command> command accomplishes
|
||||
this:</para>
|
||||
dynamic linker. Simply deleting all instances of <quote>/tools</quote> should
|
||||
leave us with the correct path to the dynamic linker. Also adjust the specs file
|
||||
so that GCC knows where to find the correct headers and Glibc start files.
|
||||
A <command>sed</command> command accomplishes this:</para>
|
||||
|
||||
<screen><userinput>gcc -dumpspecs | sed -e 's@/tools@@g' \
|
||||
-e '/\*startfile_prefix_spec:/{n;s@.*@/usr/lib/ @}' \
|
||||
|
||||
@ -5,89 +5,172 @@
|
||||
%general-entities;
|
||||
]>
|
||||
|
||||
<sect1 id="ch-bootable-grub">
|
||||
<sect1 id="ch-bootable-grub" role="wrap">
|
||||
<?dbhtml filename="grub.html"?>
|
||||
|
||||
<title>Making the LFS System Bootable</title>
|
||||
<sect1info condition="script">
|
||||
<productname>grub</productname>
|
||||
<productnumber>&grub-version;</productnumber>
|
||||
<address>&grub-url;</address>
|
||||
</sect1info>
|
||||
|
||||
<title>GRUB-&grub-version;</title>
|
||||
|
||||
<indexterm zone="ch-bootable-grub">
|
||||
<primary sortas="a-Grub">GRUB</primary>
|
||||
<secondary>configuring</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>Your shiny new LFS system is almost complete. One of the last
|
||||
things to do is to ensure that the system can be properly booted. The
|
||||
instructions below apply only to computers of IA-32 architecture,
|
||||
meaning mainstream PCs. Information on <quote>boot loading</quote> for
|
||||
other architectures should be available in the usual resource-specific
|
||||
locations for those architectures.</para>
|
||||
<sect2 role="package">
|
||||
<title/>
|
||||
|
||||
<para>Boot loading can be a complex area, so a few cautionary
|
||||
words are in order. Be familiar with the current boot loader and any other
|
||||
operating systems present on the hard drive(s) that need to be
|
||||
bootable. Make sure that an emergency boot disk is ready to
|
||||
<quote>rescue</quote> the computer if the computer becomes
|
||||
unusable (un-bootable).</para>
|
||||
<para>The GRUB package contains the GRand Unified Bootloader.</para>
|
||||
|
||||
<para>Earlier, we compiled and installed the GRUB boot loader software
|
||||
in preparation for this step. The procedure involves writing some
|
||||
special GRUB files to specific locations on the hard drive. We highly
|
||||
recommend creating a GRUB boot floppy diskette as a backup. Insert a
|
||||
blank floppy diskette and run the following commands:</para>
|
||||
<segmentedlist>
|
||||
<segtitle>&buildtime;</segtitle>
|
||||
<segtitle>&diskspace;</segtitle>
|
||||
|
||||
<seglistitem>
|
||||
<seg>&grub-ch6-sbu;</seg>
|
||||
<seg>&grub-ch6-du;</seg>
|
||||
</seglistitem>
|
||||
</segmentedlist>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="installation">
|
||||
<title>Installation of GRUB</title>
|
||||
|
||||
<caution>
|
||||
<para>This package will only build for x86 and x86_64 architectures
|
||||
containing 32-bit libs. If you chose to build on x86_64 without 32-bit
|
||||
libriaries (no multilib), then you must use LILO instead.</para>
|
||||
</caution>
|
||||
|
||||
<para>This package is known to have issues when its default
|
||||
optimization flags (including the <parameter>-march</parameter> and
|
||||
<parameter>-mcpu</parameter> options) are changed. If any environment
|
||||
variables that override default optimizations have been defined, such
|
||||
as <envar>CFLAGS</envar> and <envar>CXXFLAGS</envar>,
|
||||
unset them when building GRUB.</para>
|
||||
|
||||
<para>Start by applying the following patch to allow for better drive
|
||||
detection, fix some GCC 4.x issues, and provide better SATA support
|
||||
for some disk controllers:</para>
|
||||
|
||||
<screen><userinput remap="pre">patch -Np1 -i ../&grub-geometry-patch;</userinput></screen>
|
||||
|
||||
<para>By default, GRUB doesn't support ext2 filesystems with 256-byte inodes.
|
||||
Fix this by applying the following patch:</para>
|
||||
|
||||
<screen><userinput remap="pre">patch -Np1 -i ../&grub-inode-patch;</userinput></screen>
|
||||
|
||||
<para>Prepare GRUB for compilation:</para>
|
||||
|
||||
<screen><userinput remap="configure">./configure --prefix=/usr</userinput></screen>
|
||||
|
||||
<para>Compile the package:</para>
|
||||
|
||||
<screen><userinput remap="make">make</userinput></screen>
|
||||
|
||||
<para>To test the results, issue:</para>
|
||||
|
||||
<screen><userinput remap="test">make check</userinput></screen>
|
||||
|
||||
<para>Install the package:</para>
|
||||
|
||||
<screen><userinput remap="install">make install
|
||||
mkdir -v /boot/grub
|
||||
cp -v /usr/lib/grub/i386-pc/stage{1,2} /boot/grub</userinput></screen>
|
||||
|
||||
<para>Replace <filename class="directory">i386-pc</filename> with whatever
|
||||
directory is appropriate for the hardware in use.</para>
|
||||
|
||||
<para>The <filename class="directory">i386-pc</filename> directory
|
||||
contains a number of <filename>*stage1_5</filename> files, different
|
||||
ones for different file systems. Review the files available and copy
|
||||
the appropriate ones to the <filename
|
||||
class="directory">/boot/grub</filename> directory. Most users will
|
||||
copy the <filename>e2fs_stage1_5</filename> and/or
|
||||
<filename>reiserfs_stage1_5</filename> files.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="configuration">
|
||||
<title>Configuring GRUB</title>
|
||||
|
||||
<para>Your shiny new LFS system is almost complete. One of the last
|
||||
things to do is to ensure that the system can be properly booted. The
|
||||
instructions below apply only to computers of IA-32 architecture,
|
||||
meaning mainstream PCs. Information on <quote>boot loading</quote> for
|
||||
other architectures should be available in the usual resource-specific
|
||||
locations for those architectures.</para>
|
||||
|
||||
<para>Boot loading can be a complex area, so a few cautionary
|
||||
words are in order. Be familiar with the current boot loader and any other
|
||||
operating systems present on the hard drive(s) that need to be
|
||||
bootable. Make sure that an emergency boot disk is ready to
|
||||
<quote>rescue</quote> the computer if the computer becomes
|
||||
unusable (un-bootable).</para>
|
||||
|
||||
<para>Earlier, we compiled and installed the GRUB boot loader software
|
||||
in preparation for this step. The procedure involves writing some
|
||||
special GRUB files to specific locations on the hard drive. We highly
|
||||
recommend creating a GRUB boot floppy diskette as a backup. Insert a
|
||||
blank floppy diskette and run the following commands:</para>
|
||||
|
||||
<screen><userinput>dd if=/boot/grub/stage1 of=/dev/fd0 bs=512 count=1
|
||||
dd if=/boot/grub/stage2 of=/dev/fd0 bs=512 seek=1</userinput></screen>
|
||||
|
||||
<para>Remove the diskette and store it somewhere safe. Now, run the
|
||||
<command>grub</command> shell:</para>
|
||||
<para>Remove the diskette and store it somewhere safe. Now, run the
|
||||
<command>grub</command> shell:</para>
|
||||
|
||||
<screen><userinput>grub</userinput></screen>
|
||||
|
||||
<para>GRUB uses its own naming structure for drives and partitions in
|
||||
the form of <emphasis>(hdn,m)</emphasis>, where <emphasis>n</emphasis>
|
||||
is the hard drive number and <emphasis>m</emphasis> is the partition
|
||||
number, both starting from zero. For example, partition <filename
|
||||
class="partition">hda1</filename> is <emphasis>(hd0,0)</emphasis> to
|
||||
GRUB and <filename class="partition">hdb3</filename> is
|
||||
<emphasis>(hd1,2)</emphasis>. In contrast to Linux, GRUB does not
|
||||
consider CD-ROM drives to be hard drives. For example, if using a CD
|
||||
on <filename class="partition">hdb</filename> and a second hard drive
|
||||
on <filename class="partition">hdc</filename>, that second hard drive
|
||||
would still be <emphasis>(hd1)</emphasis>.</para>
|
||||
<para>GRUB uses its own naming structure for drives and partitions in
|
||||
the form of <emphasis>(hdn,m)</emphasis>, where <emphasis>n</emphasis>
|
||||
is the hard drive number and <emphasis>m</emphasis> is the partition
|
||||
number, both starting from zero. For example, partition <filename
|
||||
class="partition">hda1</filename> is <emphasis>(hd0,0)</emphasis> to
|
||||
GRUB and <filename class="partition">hdb3</filename> is
|
||||
<emphasis>(hd1,2)</emphasis>. In contrast to Linux, GRUB does not
|
||||
consider CD-ROM drives to be hard drives. For example, if using a CD
|
||||
on <filename class="partition">hdb</filename> and a second hard drive
|
||||
on <filename class="partition">hdc</filename>, that second hard drive
|
||||
would still be <emphasis>(hd1)</emphasis>.</para>
|
||||
|
||||
<para>Using the above information, determine the appropriate
|
||||
designator for the root partition (or boot partition, if a separate
|
||||
one is used). For the following example, it is assumed that the root
|
||||
(or separate boot) partition is <filename
|
||||
class="partition">hda4</filename>.</para>
|
||||
<para>Using the above information, determine the appropriate
|
||||
designator for the root partition (or boot partition, if a separate
|
||||
one is used). For the following example, it is assumed that the root
|
||||
(or separate boot) partition is <filename
|
||||
class="partition">hda4</filename>.</para>
|
||||
|
||||
<para>Tell GRUB where to search for its
|
||||
<filename>stage{1,2}</filename> files. The Tab key can be used
|
||||
everywhere to make GRUB show the alternatives:</para>
|
||||
<para>Tell GRUB where to search for its
|
||||
<filename>stage{1,2}</filename> files. The Tab key can be used
|
||||
everywhere to make GRUB show the alternatives:</para>
|
||||
|
||||
<screen><userinput>root (hd0,3)</userinput></screen>
|
||||
|
||||
<warning>
|
||||
<para>The following command will overwrite the current boot loader. Do not
|
||||
run the command if this is not desired, for example, if using a third party
|
||||
boot manager to manage the Master Boot Record (MBR). In this scenario, it
|
||||
would make more sense to install GRUB into the <quote>boot sector</quote>
|
||||
of the LFS partition. In this case, this next command would become
|
||||
<userinput>setup (hd0,3)</userinput>.</para>
|
||||
</warning>
|
||||
<warning>
|
||||
<para>The following command will overwrite the current boot loader. Do not
|
||||
run the command if this is not desired, for example, if using a third party
|
||||
boot manager to manage the Master Boot Record (MBR). In this scenario, it
|
||||
would make more sense to install GRUB into the <quote>boot sector</quote>
|
||||
of the LFS partition. In this case, this next command would become
|
||||
<userinput>setup (hd0,3)</userinput>.</para>
|
||||
</warning>
|
||||
|
||||
<para>Tell GRUB to install itself into the MBR of
|
||||
<filename class="partition">hda</filename>:</para>
|
||||
<para>Tell GRUB to install itself into the MBR of
|
||||
<filename class="partition">hda</filename>:</para>
|
||||
|
||||
<screen><userinput>setup (hd0)</userinput></screen>
|
||||
|
||||
<para>If all went well, GRUB will have reported finding its files in
|
||||
<filename class="directory">/boot/grub</filename>. That's all there is
|
||||
to it. Quit the <command>grub</command> shell:</para>
|
||||
<para>If all went well, GRUB will have reported finding its files in
|
||||
<filename class="directory">/boot/grub</filename>. That's all there is
|
||||
to it. Quit the <command>grub</command> shell:</para>
|
||||
|
||||
<screen><userinput>quit</userinput></screen>
|
||||
|
||||
<para>Create a <quote>menu list</quote> file defining GRUB's boot menu:</para>
|
||||
<para>Create a <quote>menu list</quote> file defining GRUB's boot menu:</para>
|
||||
|
||||
<screen><userinput>cat > /boot/grub/menu.lst << "EOF"
|
||||
<literal># Begin /boot/grub/menu.lst
|
||||
@ -107,8 +190,8 @@ root (hd0,3)
|
||||
kernel /boot/lfskernel-&linux-version; root=/dev/hda4</literal>
|
||||
EOF</userinput></screen>
|
||||
|
||||
<para>Add an entry for the host distribution if desired. It might look
|
||||
like this:</para>
|
||||
<para>Add an entry for the host distribution if desired. It might look
|
||||
like this:</para>
|
||||
|
||||
<screen><userinput>cat >> /boot/grub/menu.lst << "EOF"
|
||||
<literal>title Red Hat
|
||||
@ -117,8 +200,8 @@ kernel /boot/kernel-2.6.5 root=/dev/hda3
|
||||
initrd /boot/initrd-2.6.5</literal>
|
||||
EOF</userinput></screen>
|
||||
|
||||
<para>If dual-booting Windows, the following entry will allow
|
||||
booting it:</para>
|
||||
<para>If dual-booting Windows, the following entry will allow
|
||||
booting it:</para>
|
||||
|
||||
<screen><userinput>cat >> /boot/grub/menu.lst << "EOF"
|
||||
<literal>title Windows
|
||||
@ -126,15 +209,99 @@ rootnoverify (hd0,0)
|
||||
chainloader +1</literal>
|
||||
EOF</userinput></screen>
|
||||
|
||||
<para>If <command>info grub</command> does not provide all necessary material,
|
||||
additional information regarding GRUB is located on its website at:
|
||||
<ulink url="http://www.gnu.org/software/grub/"/>.</para>
|
||||
<para>If <command>info grub</command> does not provide all necessary material,
|
||||
additional information regarding GRUB is located on its website at:
|
||||
<ulink url="http://www.gnu.org/software/grub/"/>.</para>
|
||||
|
||||
<para>The FHS stipulates that GRUB's <filename>menu.lst</filename> file should
|
||||
be symlinked to <filename class="symlink">/etc/grub/menu.lst</filename>. To
|
||||
satisfy this requirement, issue the following command:</para>
|
||||
<para>The FHS stipulates that GRUB's <filename>menu.lst</filename> file should
|
||||
be symlinked to <filename class="symlink">/etc/grub/menu.lst</filename>. To
|
||||
satisfy this requirement, issue the following command:</para>
|
||||
|
||||
<screen><userinput>mkdir -v /etc/grub
|
||||
ln -sv /boot/grub/menu.lst /etc/grub</userinput></screen>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="contents-gRUB" role="content">
|
||||
<title>Contents of GRUB</title>
|
||||
|
||||
<segmentedlist>
|
||||
<segtitle>Installed programs</segtitle>
|
||||
|
||||
<seglistitem>
|
||||
<seg>grub, grub-install, grub-md5-crypt, grub-set-default,
|
||||
grub-terminfo, and mbchk</seg>
|
||||
</seglistitem>
|
||||
</segmentedlist>
|
||||
|
||||
<variablelist>
|
||||
<bridgehead renderas="sect3">Short Descriptions</bridgehead>
|
||||
<?dbfo list-presentation="list"?>
|
||||
<?dbhtml list-presentation="table"?>
|
||||
|
||||
<varlistentry id="grub">
|
||||
<term><command>grub</command></term>
|
||||
<listitem>
|
||||
<para>The Grand Unified Bootloader's command shell</para>
|
||||
<indexterm zone="ch-bootable-grub grub">
|
||||
<primary sortas="b-grub">grub</primary>
|
||||
</indexterm>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id="grub-install">
|
||||
<term><command>grub-install</command></term>
|
||||
<listitem>
|
||||
<para>Installs GRUB on the given device</para>
|
||||
<indexterm zone="ch-bootable-grub grub-install">
|
||||
<primary sortas="b-grub-install">grub-install</primary>
|
||||
</indexterm>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id="grub-md5-crypt">
|
||||
<term><command>grub-md5-crypt</command></term>
|
||||
<listitem>
|
||||
<para>Encrypts a password in MD5 format</para>
|
||||
<indexterm zone="ch-bootable-grub grub-md5-crypt">
|
||||
<primary sortas="b-grub-md5-crypt">grub-md5-crypt</primary>
|
||||
</indexterm>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id="grub-set-default">
|
||||
<term><command>grub-set-default</command></term>
|
||||
<listitem>
|
||||
<para>Sets the default boot entry for GRUB</para>
|
||||
<indexterm zone="ch-bootable-grub grub-set-default">
|
||||
<primary sortas="b-grub-set-default">grub-set-default</primary>
|
||||
</indexterm>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id="grub-terminfo">
|
||||
<term><command>grub-terminfo</command></term>
|
||||
<listitem>
|
||||
<para>Generates a terminfo command from a terminfo name; it can be
|
||||
employed if an unknown terminal is being used</para>
|
||||
<indexterm zone="ch-bootable-grub grub-terminfo">
|
||||
<primary sortas="b-grub-terminfo">grub-terminfo</primary>
|
||||
</indexterm>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id="mbchk">
|
||||
<term><command>mbchk</command></term>
|
||||
<listitem>
|
||||
<para>Checks the format of a multi-boot kernel</para>
|
||||
<indexterm zone="ch-bootable-grub mbchk">
|
||||
<primary sortas="b-mbchk">mbchk</primary>
|
||||
</indexterm>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<!ENTITY version "SVN-20081203">
|
||||
<!ENTITY releasedate "December 3, 2008">
|
||||
<!ENTITY version "SVN-20081204">
|
||||
<!ENTITY releasedate "December 4, 2008">
|
||||
<!ENTITY copyrightdate "1999-2008"><!-- jhalfs needs a literal dash, not – -->
|
||||
<!ENTITY milestone "7.0">
|
||||
<!ENTITY generic-version "development"> <!-- Use "development", "testing", or "x.y[-pre{x}]" -->
|
||||
|
||||
@ -57,6 +57,9 @@
|
||||
<!ENTITY expect-tcl-patch-md5 "6904a384960ce0e8f0d0b32f7903d7a1">
|
||||
<!ENTITY expect-tcl-patch-size "4.1 KB">
|
||||
|
||||
<!ENTITY gcc-startfiles-patch "gcc-&gcc-version;-startfiles_fix-1.patch">
|
||||
<!ENTITY gcc-startfiles-patch-md5 "799ef1971350d2e3c794f2123f247cc6">
|
||||
<!ENTITY gcc-startfiles-patch-size "1.5 KB">
|
||||
|
||||
<!ENTITY glibc-iconv-test-fixes-patch "glibc-&glibc-version;-iconv_tests-1.patch">
|
||||
<!ENTITY glibc-iconv-test-fixes-patch-md5 "cc5e95e418e0b2f8a54b14cf90c7c3b2">
|
||||
|
||||
Loading…
Reference in New Issue
Block a user