Grammar fixes.

git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@364 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Simon Perreault 2001-03-25 08:46:07 +00:00
parent c85f9761b0
commit 13dd793404
7 changed files with 23 additions and 23 deletions

View File

@ -14,12 +14,12 @@ to the value -all-static causes binutils to be linked statically.
</para>
<para>
<userinput>tooldir=$LFS/usr:</userinput> Normally the tooldir (the
<userinput>tooldir=$LFS/usr:</userinput> Normally, the tooldir (the
directory where the executables from binutils end up in) is set to
$(exec_prefix)/$(target_alias) which expands into, for example,
/usr/i686-pc-linux-gnu. Since we only build for our own system we don't
/usr/i686-pc-linux-gnu. Since we only build for our own system, we don't
need this target specific directory in $LFS/usr. That setup would be used
if the system is used to cross-compile (for example
if the system was used to cross-compile (for example
compiling a package on the Intel machine that generates code that can be
executed on Apple PowerPC machines).
</para>

View File

@ -3,7 +3,7 @@
<para>
<userinput>sed: </userinput> The sed command here searches for the
string "$(CC) $(CFLAGS) -o" and replaced it by "$(CC) $(CFLAGS)
string "$(CC) $(CFLAGS) -o" and replaces it by "$(CC) $(CFLAGS)
$(LDFLAGS) -o" in the Makefile file. We make that modification so it
will be easier to link bzip2 statically.
</para>
@ -11,10 +11,10 @@ will be easier to link bzip2 statically.
<para>
<userinput>...Makefile | make -f -:</userinput> Makefile
is the last parameter of the sed command which indicates the file to
search and replace in. sed normally sends the modified file to stdout
(standard output) which will be the console. With the construction we
use, sed's output will be piped to the make program. Normally when make
is started it tries to find a number of files like Makefile. But we have
search and replace in. Sed normally sends the modified file to stdout
(standard output), which will be the console. With the construction we
use, sed's output will be piped to the make program. Normally, when make
is started, it tries to find a number of files like Makefile. But we have
modified the Makefile file so we don't want make to use it. The "-f -"
parameter tells make to read it's input from another file, or from stdin
(standard input) which the dash (-) implies. This is one way to do it.

View File

@ -4,8 +4,8 @@
<para>
<userinput>--enable-languages=c,c++:</userinput> This only builds the C
and C++ compilers and not the other available compilers as they are, on
the average, not often used. If those other compilers are needed
the --enable-languages parameter can be omitted..
the average, not often used. If those other compilers are needed,
the --enable-languages parameter can be omitted.
</para>
<para>

View File

@ -2,7 +2,7 @@
<title>Installation of Gzip</title>
<para>
Before Gzip is installed the the gzip patch file needs to be unpacked.
Before Gzip is installed, the gzip patch file needs to be unpacked.
</para>
<blockquote><literallayout>

View File

@ -2,19 +2,19 @@
<title>Install all software as user root</title>
<para>
It's best if the user logins as root or su's to root when installing these
files. That way he is assured that all files are owned by user root,
group root (and not owned by the userid of the non-root user) and if a
package wants to set special permissions it can do so without problems
It's best if the user logs in as root or su's to root when installing these
files. That way he is assured that all files are owned by user and
group root (and not owned by the userid of the non-root user), and if a
package wants to set special permissions, it can do so without problems
due to non-root access.
</para>
<para>
The documentation that comes with Glibc, Gcc and other
The documentation that comes with Glibc, Gcc, and other
packages recommend not to compile the packages as user root. We
feel it's safe to ignore that recommendation and compile as user root
anyways. Hundreds of people using LFS have done so without any problems
whatsoever and we haven't encountered any bugs in the compile processes
anyway. Hundreds of people using LFS have done so without any problems
whatsoever, and we haven't encountered any bugs in the compile processes
that cause harm. So it's pretty safe (never can be 100% safe though, so
it's up to the user what he ends up doing).
</para>

View File

@ -11,7 +11,7 @@ that the LFS system can be booted.
<para>
The software in this chapter will be linked statically. These programs
will be re-installed in the next chapter and linked dynamically. The
will be reinstalled in the next chapter and linked dynamically. The
reason for the static version first is that there is a chance that our
normal Linux system and the LFS system aren't using the same C
Library versions. If the programs in the first part are linked against
@ -32,10 +32,10 @@ packages will be, as previously explained, linked statically.
</para>
<para>
During the installation of various packages the user will most likely see
During the installation of various packages, the user will most likely see
compiler warnings scrolling by on the screen. These are normal and can
be safely ignored. They are just that, warnings (mostly about improper
use of the C or C++ syntax, but not illegal use. It's just that often C
use of the C or C++ syntax, but not illegal use. It's just that, often, C
standards changed and packages still use the old standard which is not a
problem).
</para>

View File

@ -6,8 +6,8 @@
answers "Y" to every question the config script asks the user. We're not
configuring the real kernel here, we just need to have some sort of
configure file created so that we can run make dep next that will create
a few files in $LFS/usr/src/linux/include/linux like version.h among
others that we will need to compilg Glibc and other packages later in
a few files in $LFS/usr/src/linux/include/linux, like version.h, among
others, that we will need to compilg Glibc and other packages later in
chroot.
</para>