mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-03-05 22:04:48 +00:00
You
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@337 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
parent
53b5ccf173
commit
81a47c0302
@ -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.
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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".
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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.
|
||||
|
Loading…
Reference in New Issue
Block a user