git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@337 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Thomas Balu Walter 2001-03-19 16:02:50 +00:00
parent 53b5ccf173
commit 81a47c0302
23 changed files with 111 additions and 102 deletions

View File

@ -5,32 +5,33 @@
Most programs and libraries by default are compiled with debugging
symbols and optimizing level 2 (gcc options -g and -O2) and are compiled
for a specific CPU. On Intel platforms software is compiled for i386
processors by default. If you don't wish to run software on other
machines other than your own, you might want to change the default
processors by default. If a user doesn't wish to run software on other
machines other than his own, he might want to change the default
compiler options so that they will be compiled with a higher
optimization level, no debugging symbols and generate code for your
optimization level, no debugging symbols and generate code for his
specific architecture. Let me first explain what debugging symbols
are.
</para>
<para>
A program compiled with debugging symbols means you can run a program or
A program compiled with debugging symbols means a user can run a program or
library through a debugger and the debugger's output will be user friendlier.
These debugging symbols also enlarge the program or library significantly.
These debugging symbols also enlarge the program or library significantly.
</para>
<para>
To remove debugging symbols from a binary (must be an a.out or ELF binary)
run <userinput>strip --strip-debug filename</userinput> You can use wild cards
if you need to strip debugging symbols from multiple files (use something like
run <userinput>strip --strip-debug filename</userinput>. A user can use wild
cards
if he needs to strip debugging symbols from multiple files (use something like
strip --strip-debug $LFS/usr/bin/*). Another, easier, options is just
not to compile programs with debugging symbols. Most people will probably
never use a debugger on software, so by leaving those symbols out you
can save a lot of diskspace.
never use a debugger on software, so by leaving those symbols out
a lot of diskspace can be saved.
</para>
<para>
Before you wonder if these debugging symbols would make a big difference,
Before someone wonders if these debugging symbols would make a big difference,
here are some statistics:
</para>
@ -58,8 +59,8 @@ here are some statistics:
<para>
Sizes may vary depending on which compiler was used and which C library
version was used to link dynamic programs against, but your results will be
similar if you compare programs with and without debugging symbols. After
version was used to link dynamic programs against, but results will be
similar if a user compares programs with and without debugging symbols. After
I was done with this chapter and stripped all debugging symbols from all LFS
binaries and libraries I regained a little over 102 MB of disk space. Quite
the difference.

View File

@ -16,8 +16,8 @@ Install Bash by running the following commands:
</literallayout></blockquote>
<para>
Replace the static bash with the dynamic bash and re-enter the chroot'ed
environment by running:
The static bash is replaced with the dynamic bash and the chroot'ed
environment is re-entered by running:
</para>
<blockquote><literallayout>

View File

@ -4,7 +4,8 @@
<para>
When we have entered the chroot'ed environment in the next section we
want to export a couple of environment variables in that shell such as
PS1, PATH and others variables you want to have set. For that purpose we'll
PS1, PATH and others variables a user wants to have set. For that
purpose we'll
create the $LFS/root/.bash_profile file which will be read by bash when we
enter the chroot environment.
</para>
@ -30,8 +31,9 @@ export PS1 PATH
</literallayout>
<para>
You can add more environment variables,aliases and whatever else you
need/want at your own discretion as you deem them necessary.
More environment variables,aliases and whatever else is
needed/wanted can be added at the users own discretion
as he deems them necessary.
</para>
</sect1>

View File

@ -2,7 +2,7 @@
<title>Command explanations</title>
<para>
<userinput>--datadir=/usr/share/bison:</userinput> This install the
<userinput>--datadir=/usr/share/bison:</userinput> This installs the
bison grammar files in /usr/share/bison rather than /usr/share.
</para>

View File

@ -28,13 +28,13 @@ Install Bzip2 by running the following commands:
<para>
Although it's not strictly a part of a basic LFS system it's worth
mentioning that you can download a patch for Tar which enables the tar
mentioning that a patch for Tar can be downloaded which enables the tar
program to compress and uncompress using bzip2/bunzip2 easily. With a
plain tar you'll have to use constructions like bzcat file.tar.bz|tar
plain tar a user has to use constructions like bzcat file.tar.bz|tar
xv or tar --use-compress-prog=bunzip2 -xvf file.tar.bz2 to use bzip2 and
bunzip2 with tar. This patch gives you the -y option so you can unpack a
bunzip2 with tar. This patch gives the -y option so a user can unpack a
Bzip2 archive with tar xvfy file.tar.bz2. Applying this patch will be
mentioned later on when you re-install the Tar package.
mentioned later on when the Tar package is re-installed.
</para>
</sect2>

View File

@ -9,7 +9,7 @@ rest of the software we need.
<para>
Enter the following command to enter the chroot'ed environment. From
this point on there's no need to use the $LFS variable anymore, because
everything you do will be restricted to the LFS partition (since / is
everything a user does will be restricted to the LFS partition (since / is
actually /mnt/lfs but the shell doesn't know that).
</para>
@ -30,11 +30,11 @@ like vim and less to operate properly.
<para>
Now that we are inside a chroot'ed environment, we can continue to
install all the basic system software. Make sure you execute all the
following commands in this and following chapters from within the
chroot'ed environment. If you ever leave this environment for a reason
(say when you reboot or something) don't forget to mount $LFS/proc again
like you did earlier and to re-enter chroot before you continue with the
install all the basic system software. A user has to make sure all the
following commands in this and following chapters are run from within the
chroot'ed environment. If he ever leaves this environment for a reason
(say when rebooting or something) he has to remember to mount $LFS/proc again
like he did earlier and to re-enter chroot before continuing with the
book.
</para>

View File

@ -39,9 +39,10 @@ netgroup: db files
</literallayout>
<para>
Run the <userinput>tzselect</userinput> script and answer the questions
regarding your timezone. When you're done, the script will give you the
location of the timezone file you need.
The <userinput>tzselect</userinput> script has to be run and the questions
regarding the user's timezone have to be answered.
When the user is done, the script will give the
location of the needed timezone file.
</para>
<para>
@ -63,7 +64,7 @@ tzselect's output can be something like <emphasis>EST5EDT</emphasis> or
</para>
<para>
The symlink you would create with that information would be:
The symlink a user would create with that information would be:
</para>
<blockquote><literallayout>

View File

@ -4,11 +4,11 @@
<para>
By default the dynamic loader searches a few default paths for dynamic
libraries, so there normally isn't a need for the
<filename>/etc/ld.so.conf</filename> file unless you have extra
directories in which you want the system to search for paths. The
<filename>/etc/ld.so.conf</filename> file unless the system has extra
directories in which a user wants the system to search for paths. The
<filename class="directory">/usr/local/lib</filename> directory isn't
searched through for dynamic libraries by default, so we want to add
this path so when you install software you won't be suprised by them not
this path so when a user installs software he won't be suprised by them not
running for some reason.
</para>
@ -35,8 +35,9 @@ following:
Although it's not necessary to add the
<filename class="directory">/lib</filename> and
<filename class="directory">/usr/lib</filename> directories it doesn't
hurt. This way you see right away what's being searched and don't have
to remeber the default search paths if you don't want to.
hurt. This way it can be seen right away what's being searched and a user
doesn't have
to remeber the default search paths if he doesn't want to.
</para>
</sect2>

View File

@ -3,16 +3,16 @@
<para>
We're not going to create lilo's configuration file from scratch, but we'll
use the file from your normal Linux system. This file is different on every
machine and thus I can't create it here. Since you would want to have the
same options regarding lilo as you have when you're using your normal Linux
system you would create the file exactly as it is on the normal system.
use the file from the normal Linux system. This file is different on every
machine and thus I can't create it here. Since a user would want to have the
same options regarding lilo as he has when he is using his normal Linux
system he would create the file exactly as it is on the normal system.
</para>
<para>
Copy the Lilo configuration file and kernel images that Lilo uses by
running the following commands from a shell on your normal Linux system.
Don't execute these commands from your chroot'ed shell.
running the following commands from a shell on the normal Linux system.
Don't execute these commands from the chroot'ed shell.
</para>
<blockquote><literallayout>
@ -23,10 +23,10 @@ Don't execute these commands from your chroot'ed shell.
</literallayout></blockquote>
<para>
Before you can execute the second command you need to know the names of
the kernel images. You can't just copy all files from the /boot
Before a user can execute the second command he needs to know the names of
the kernel images. He can't just copy all files from the /boot
directory. The /etc/lilo.conf file contains the names of the kernel
images you're using. Open the file and look for lines like this:
images he is using. Open the file and look for lines like this:
</para>
<blockquote><literallayout>
@ -39,7 +39,7 @@ images you're using. Open the file and look for lines like this:
Look for all <emphasis>image</emphasis> variables and their values
represent the name and location of the image files. These files will
usually be in /boot but they might be in other directories as well,
depending on your distribution's conventions.
depending on the distribution's conventions.
</para>
</sect2>

View File

@ -2,10 +2,10 @@
<para>
This package contains the utilities to modify user's passwords, add new
users/groups, delete users/groups and more. I'm not going to explain to you
what 'password shadowing' means. You can read all about that in the doc/HOWTO
users/groups, delete users/groups and more. I'm not going to explain
what 'password shadowing' means. All about that can be read in the doc/HOWTO
file within the unpacked shadow password suite's source tree. There's one
thing you should keep in mind, if you decide to use shadow support, that
thing a user should keep in mind, if he decides to use shadow support, that
programs that need to verify passwords (examples are xdm, ftp daemons,
pop3 daemons, etc) need to be 'shadow-compliant', eg. they need to
be able to work with shadow'ed passwords.
@ -17,17 +17,18 @@ shadow password suite does not enable shadow'ed passwords.
</para>
<para>
Now is a very good moment to read chapter 5 of the doc/HOWTO file. You can
read how you can enable shadow'ed passwords, how to test whether shadowing
Now is a very good moment to read chapter 5 of the doc/HOWTO file. It
describes
how to enable shadow'ed passwords, how to test whether shadowing
works and if not, how to disable it again.
</para>
<para>
The documentation mentions something about the creation of npasswd and
nshadow after you run pwconv. This is an error in the documentation.
Those two files will be be created. After you run pwconv, /etc/passwd
will no longer contain the passwords and /etc/shadow will. You don't
need to rename the npasswd and nshadow files yourself.
nshadow after pwconv is run. This is an error in the documentation.
Those two files will not be created. After pwconv is run, /etc/passwd
will no longer contain the passwords and /etc/shadow will. A user doesn't
need to rename the npasswd and nshadow files himself.
</para>
</sect2>

View File

@ -2,7 +2,7 @@
<title>Installation of Console-tools</title>
<para>
Before you start installing Console-tools you have to unpack the
Before starting to install Console-tools a user has to unpack the
console-tools-0.2.3.patch file.
</para>

View File

@ -2,8 +2,7 @@
<title>Installing Findutils</title>
<para>
Before you install Findutils you have to unpack the findutils patch
file.
Before Findutils is installed the findutils patch file has to be unpacked.
</para>
<para>

View File

@ -2,8 +2,9 @@
<title>Installation of GCC</title>
<para>
After you unpacked the gcc-2.95.2.1 archive don't enter the newly created
gcc-2.95.2.1 directory but stay in the /usr/src directory. Install GCC by
After a user unpacked the gcc-2.95.2.1 archive he doesn't enter the
newly created
gcc-2.95.2.1 directory but stays in the /usr/src directory. Install GCC by
running the following commands:
</para>

View File

@ -40,8 +40,8 @@ Install Glibc by running the following commands:
</literallayout></blockquote>
<para>
You can get rid of the "I have no name!" in the bash prompt if you want.
Do this by exiting chroot and re-entering it. Run the following
A user can get rid of the "I have no name!" in the bash prompt if he wants.
This is done by exiting chroot and re-entering it. Run the following
commands to do that:
</para>

View File

@ -3,10 +3,10 @@
<para>
The installation of all the software is pretty straightforward and
you'll think it's so much easier and shorter to give the generic
a user will think it's so much easier and shorter to give the generic
installation instructions for each package and only explain how to
install something if a certain package requires an alternate installation
method. Although I agree with you on that, I, however, choose to give the
method. Although I agree on that, I, however, choose to give the
full instructions for each and every package. This is simply to avoid any
possible confusion and errors.
</para>

View File

@ -14,14 +14,14 @@ Install Lilo by running the following commands:
<para>
It appears that compilation of this package fails on certain machines
when the -g compiler flag is being used. If you can't compile Lilo at
all, please try removing the -g value from the CFLAGS variable in the
when the -g compiler flag is being used. If a user can't compile Lilo at
all, he should try to remove the -g value from the CFLAGS variable in the
<filename>Makefile</filename> file.
</para>
<para>
At the end of the installation the make install process will print a
message stating that you have to execute /sbin/lilo to complete the
message stating that /sbin/lilo has to be executed to complete the
update. Don't do this as it has no use. The /etc/lilo.conf isn't present
yet. We will complete the installation of lilo in chapter 8.
</para>

View File

@ -14,16 +14,16 @@ Install M4 by running the following commands:
</literallayout></blockquote>
<para>
If you're base system is running a 2.0 kernel and your Glibc version is
2.1 then you will most likely get problems executing M4 in the
If the base system is running a 2.0 kernel and the Glibc version is
2.1 then a user will most likely get problems executing M4 in the
chroot'ed environment due to incompatibilities between the M4 program,
Glibc-2.1 and the running 2.0 kernel. If you have problems executing the
m4 program in the chroot'ed environment (for example when you install
the autoconf and automake packages) you'll have to exit the chroot'ed
Glibc-2.1 and the running 2.0 kernel. If he has problems executing the
m4 program in the chroot'ed environment (for example when he installs
the autoconf and automake packages) he'll have to exit the chroot'ed
environment and compile M4 statically. This way the binary is linked
against Glibc 2.0 (if you run kernel 2.0 you're Glibc version is 2.0 as
against Glibc 2.0 (if he runs kernel 2.0, Glibc version is 2.0 as
well on a decent system. Kernel 2.0 and Glibc-2.1 don't mix very well)
and won't give you any problems.
and won't give any problems.
</para>
<para>
@ -42,9 +42,10 @@ commands:
</literallayout></blockquote>
<para>
Now you can re-enter the chroot'ed environment and continue with the
next package. If you wish to recompile M4 dynamically, you can do that
after you have rebooted into the LFS system rather than chroot'ed into it.
Now the chroot'ed environment can be re-entered and the
next package an be installed. If M4 should be re-compiled dynamically,
this can be done
after having rebooted into the LFS system rather than chrooting into it.
</para>
<blockquote><literallayout>

View File

@ -15,17 +15,18 @@ Create the device files by running the following commands:
<para>
The <quote>generic</quote> parameter passed to the MAKEDEV script
doesn't create all the devices you might need, such as audio devices,
hdc, hdd and ohters. If you seem to be missing something tell MAKEDEV to
create it. To create hdc replace generic with hdc. You can also add hdc
to generic, so you would execute <userinput>./MAKEDEV -v generic
doesn't create all the devices a user might need, such as audio devices,
hdc, hdd and ohters. If it seems something is missing MAKEDEV has to be told
to
create it. To create hdc replace generic with hdc. A user can also add hdc
to generic, so he would execute <userinput>./MAKEDEV -v generic
hdc</userinput> to create the generic set of devices files, plus the
files you need to be able to access hdc (and hdc1, hdc2, etc)
files he needs to be able to access hdc (and hdc1, hdc2, etc)
</para>
<para>
MAKEDEV will create hda[1-20] and hdb[1-20] and such but keep in mind
that you may not be able to use all of those devices due to kernel
MAKEDEV will create hda[1-20] and hdb[1-20] and such but he has to keep in mind
that he may not be able to use all of those devices due to kernel
limitations regarding the max. number of partitions.
</para>

View File

@ -14,10 +14,10 @@ Install Perl by running the following commands:
</literallayout></blockquote>
<para>
If you don't want to answer all those questions Perl asks you, you can
If a user doesn't want to answer all those questions Perl asks, he can
add the -d option to the configure script and Perl will use all the
default settings. To avoid the Configure script asking you questions
after the config.sh file has been created you can pass the -e parameter
default settings. To avoid the Configure script asking questions
after the config.sh file has been created he can pass the -e parameter
to perl as well. The commands with these parameters included will be:
</para>

View File

@ -2,8 +2,8 @@
<title>Removing old NSS library files</title>
<para>
If you have copied the NSS Library files from your normal Linux system to the
LFS system (because your normal system runs glibc-2.0) it's time to remove
If the user copied the NSS Library files from the normal Linux system to the
LFS system (because the normal system runs glibc-2.0) it's time to remove
them now by running:
</para>

View File

@ -2,12 +2,12 @@
<title>Installation of Sysvinit</title>
<para>
When you change run levels (for example when you are going to shutdown
your system) the init program is going to send the TERM and KILL signals
When run levels are changed (for example when going to shutdown
the system) the init program is going to send the TERM and KILL signals
to all the processes that init started. But init prints a message to the
screen saying "sending all processes the TERM signal" and the same for the
KILL signal. This implies that init sends this signal to all the currently
running processes, which isn't the case. To avoid this confusion you can
running processes, which isn't the case. To avoid this confusion a user can
apply the sysvinit patch found on the LFS FTP site to sysvinit that changes
the sentence in the shutdown.c file and have it print "sending all
processes started by init the TERM signal".

View File

@ -2,9 +2,10 @@
<title>Installation of Tar</title>
<para>
If you want to be able to directly use bzip2 files with tar, use the tar
If a user wants to be able to directly use bzip2 files with tar, he can
use the tar
patch avaiable from the LFS FTP site. This patch will add the -y option
to tar which works the same as the -z option to tar (which you can use
to tar which works the same as the -z option to tar (which can be used
for gzip files).
</para>

View File

@ -2,19 +2,19 @@
<title>Installation of Vim</title>
<para>
If you don't like vim to be installed as an editor on your LFS system,
you may want to download an alternative and install an editor you
prefer. There are a few hints how to install different editors
If a user doesn't like vim to be installed as an editor on the LFS system,
he may want to download an alternative and install an editor he
prefers. There are a few hints how to install different editors
available at <ulink
url="http://cvs.linuxfromscratch.org/index.cgi/hints/editors/">
http://cvs.linuxfromscratch.org/index.cgi/hints/editors/</ulink>
</para>
<para>
You need to unpack both the vim-rt and vim-src packages to install Vim.
Both the vim-rt and vim-src packages need to be unpacked to install Vim.
Both packages will unpack their files into the vim-5.7 directory. This
won't overwrite any files from the other package. So it doesn't mattter
in which order you do it. Install Vim by running the following commands:
in which order it is done. Install Vim by running the following commands:
</para>
<blockquote><literallayout>
@ -28,8 +28,8 @@ in which order you do it. Install Vim by running the following commands:
</literallayout></blockquote>
<para>
If you are planning on installing the X Window system on your LFS
system, you might want to re-compile Vim after you have installed X. Vim
If a user plans on installing the X Window system on his LFS
system, he might want to re-compile Vim after he has installed X. Vim
comes with a nice GUI version of the editor which requires X and a few
other libraries to be installed. For more information read the Vim
documentation.