mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-03-06 14:24:48 +00:00
Merge remote-tracking branch 'origin/trunk' into xry111/arm64
This commit is contained in:
commit
1ace4659a7
@ -11,11 +11,11 @@
|
||||
<title>Entering the Chroot Environment</title>
|
||||
|
||||
<para>Now that all the packages which are required to build the rest of the
|
||||
needed tools are on the system, it is time to enter the chroot environment to
|
||||
finish installing the remaining temporary tools. This environment will be in
|
||||
use also for installing the final system. As user <systemitem
|
||||
needed tools are on the system, it is time to enter the chroot environment and
|
||||
finish installing the temporary tools. This environment will also be
|
||||
used to install the final system. As user <systemitem
|
||||
class="username">root</systemitem>, run the following command to enter the
|
||||
environment that is, at the moment, populated with only the temporary
|
||||
environment that is, at the moment, populated with nothing but temporary
|
||||
tools:</para>
|
||||
|
||||
<screen role="nodump"><userinput>chroot "$LFS" /usr/bin/env -i \
|
||||
@ -26,25 +26,26 @@
|
||||
/bin/bash --login</userinput></screen>
|
||||
|
||||
<para>The <parameter>-i</parameter> option given to the <command>env</command>
|
||||
command will clear all variables of the chroot environment. After that, only
|
||||
command will clear all the variables in the chroot environment. After that, only
|
||||
the <envar>HOME</envar>, <envar>TERM</envar>, <envar>PS1</envar>, and
|
||||
<envar>PATH</envar> variables are set again. The
|
||||
<parameter>TERM=$TERM</parameter> construct will set the <envar>TERM</envar>
|
||||
<parameter>TERM=$TERM</parameter> construct sets the <envar>TERM</envar>
|
||||
variable inside chroot to the same value as outside chroot. This variable is
|
||||
needed for programs like <command>vim</command> and <command>less</command>
|
||||
to operate properly. If other variables are desired, such as
|
||||
needed so programs like <command>vim</command> and <command>less</command>
|
||||
can operate properly. If other variables are desired, such as
|
||||
<envar>CFLAGS</envar> or <envar>CXXFLAGS</envar>, this is a good place to set
|
||||
them again.</para>
|
||||
them.</para>
|
||||
|
||||
<para>From this point on, there is no need to use the
|
||||
<envar>LFS</envar> variable anymore because all work will be restricted
|
||||
to the LFS file system. This is because the Bash shell is told that
|
||||
<filename class="directory">$LFS</filename> is now the root
|
||||
(<filename class="directory">/</filename>) directory.</para>
|
||||
<envar>LFS</envar> variable any more because all work will be restricted
|
||||
to the LFS file system; the <command>chroot</command> command runs the
|
||||
Bash shell with the root
|
||||
(<filename class="directory">/</filename>) directory set to
|
||||
<filename class='directory'>$LFS</filename>.</para>
|
||||
|
||||
<para>Notice that <filename class="directory">/tools/bin</filename> is not
|
||||
in the <envar>PATH</envar>. This means that the cross toolchain will no longer be
|
||||
used in the chroot environment.</para>
|
||||
used.</para>
|
||||
|
||||
<para>Note that the <command>bash</command> prompt will say
|
||||
<computeroutput>I have no name!</computeroutput> This is normal because the
|
||||
|
@ -13,15 +13,15 @@
|
||||
<sect2>
|
||||
<title>Cleaning</title>
|
||||
|
||||
<para>First, remove the currently installed documentation to prevent them
|
||||
<para>First, remove the currently installed documentation files to prevent them
|
||||
from ending up in the final system, and to save about 35 MB:</para>
|
||||
|
||||
<screen><userinput>rm -rf /usr/share/{info,man,doc}/*</userinput></screen>
|
||||
|
||||
<para>Second, on a modern Linux system, the libtool .la files are only
|
||||
useful for libltdl. No libraries in LFS are expected to be loaded by
|
||||
libltdl, and it's known that some .la files can cause BLFS packages
|
||||
fail to build. Remove those files now:</para>
|
||||
useful for libltdl. No libraries in LFS are loaded by
|
||||
libltdl, and it's known that some .la files can cause BLFS package
|
||||
failures. Remove those files now:</para>
|
||||
|
||||
<screen><userinput>find /usr/{lib,libexec} -name \*.la -delete</userinput></screen>
|
||||
|
||||
@ -42,9 +42,9 @@
|
||||
and your current LFS system is in a good state. Your system can now be
|
||||
backed up for later reuse. In case of fatal failures in the subsequent
|
||||
chapters, it often turns out that removing everything and starting over
|
||||
(more carefully) is the best option to recover. Unfortunately, all the
|
||||
(more carefully) is the best way to recover. Unfortunately, all the
|
||||
temporary files will be removed, too. To avoid spending extra time to
|
||||
redo something which has been built successfully, creating a backup of
|
||||
redo something which has been done successfully, creating a backup of
|
||||
the current LFS system may prove useful.
|
||||
</para>
|
||||
|
||||
@ -58,13 +58,12 @@
|
||||
|
||||
<para>
|
||||
The following steps are performed from outside the chroot
|
||||
environment. That means, you have to leave the chroot environment
|
||||
environment. That means you have to leave the chroot environment
|
||||
first before continuing. The reason for that is to
|
||||
get access to file system locations outside of the chroot
|
||||
environment to store/read the backup archive which should
|
||||
environment to store/read the backup archive, which ought
|
||||
not be placed within the
|
||||
<filename class="directory">$LFS</filename> hierarchy for
|
||||
safety reasons.
|
||||
<filename class="directory">$LFS</filename> hierarchy.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -78,7 +77,7 @@
|
||||
All of the following instructions are executed by
|
||||
<systemitem class="username">root</systemitem> on your host system.
|
||||
Take extra care about the commands you're going to run as mistakes
|
||||
here can modify your host system. Be aware that the
|
||||
made here can modify your host system. Be aware that the
|
||||
environment variable <envar>LFS</envar>
|
||||
is set for user <systemitem class="username">lfs</systemitem> by default
|
||||
but may <emphasis>not</emphasis> be set for
|
||||
@ -101,17 +100,14 @@ umount $LFS/{sys,proc,run,dev}</userinput></screen>
|
||||
|
||||
<para>
|
||||
Make sure you have at least 1 GB free disk space (the source tarballs
|
||||
will be included in the backup archive) on the filesystem containing
|
||||
directory where you create the backup archive.
|
||||
will be included in the backup archive) on the file system containing
|
||||
the directory where you create the backup archive.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Note that the instructions below specify the home directory of the host
|
||||
system's <systemitem class="username">root</systemitem> user, which is
|
||||
typically found on the root filesystem.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
typically found on the root file system.
|
||||
Replace <envar>$HOME</envar> by a directory of your choice if you
|
||||
do not want to have the backup stored in <systemitem
|
||||
class="username">root</systemitem>'s home directory.
|
||||
@ -149,7 +145,7 @@ tar -cJpf $HOME/lfs-temp-tools-&version;.tar.xz .</userinput></screen>
|
||||
Since the sources are located under
|
||||
<filename class="directory">$LFS</filename>, they are included in the
|
||||
backup archive as well, so they do not need to be downloaded again. After
|
||||
checking that <envar>$LFS</envar> is set properly,
|
||||
checking that <envar>$LFS</envar> is set properly, you can
|
||||
restore the backup by executing the following commands:
|
||||
</para>
|
||||
|
||||
@ -167,7 +163,7 @@ rm -rf ./*
|
||||
tar -xpf $HOME/lfs-temp-tools-&version;.tar.xz</computeroutput></screen>
|
||||
|
||||
<para>
|
||||
Again, double check that the environment has been setup properly
|
||||
Again, double check that the environment has been set up properly
|
||||
and continue building the rest of the system.
|
||||
</para>
|
||||
|
||||
@ -175,7 +171,7 @@ tar -xpf $HOME/lfs-temp-tools-&version;.tar.xz</computeroutput></screen>
|
||||
<para>
|
||||
If you left the chroot environment to create a backup or restart
|
||||
building using a restore, remember to check that the virtual
|
||||
filesystems are still mounted (<command>findmnt | grep
|
||||
file systems are still mounted (<command>findmnt | grep
|
||||
$LFS</command>). If they are not mounted, remount them now as
|
||||
described in <xref linkend='ch-tools-kernfs'/> and re-enter the chroot
|
||||
environment (see <xref linkend='ch-tools-chroot'/>) before continuing.
|
||||
|
@ -34,11 +34,11 @@
|
||||
<primary sortas="e-/var/log/wtmp">/var/log/wtmp</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>Historically, Linux maintains a list of the mounted file systems in the
|
||||
<para>Historically, Linux maintained a list of the mounted file systems in the
|
||||
file <filename>/etc/mtab</filename>. Modern kernels maintain this list
|
||||
internally and expose it to the user via the <filename
|
||||
class="directory">/proc</filename> filesystem. To satisfy utilities that
|
||||
expect the presence of <filename>/etc/mtab</filename>, create the following
|
||||
expect to find <filename>/etc/mtab</filename>, create the following
|
||||
symbolic link:</para>
|
||||
|
||||
<screen><userinput>ln -sv /proc/self/mounts /etc/mtab</userinput></screen>
|
||||
@ -159,13 +159,13 @@ EOF</userinput></screen>
|
||||
|
||||
<para>The created groups are not part of any standard—they are groups
|
||||
decided on in part by the requirements of the Udev configuration in Chapter
|
||||
9, and in part by common convention employed by a number of existing Linux
|
||||
9, and in part by common conventions employed by a number of existing Linux
|
||||
distributions. In addition, some test suites rely on specific users or
|
||||
groups. The Linux Standard Base (LSB, available at <ulink
|
||||
url="https://refspecs.linuxfoundation.org/lsb.shtml"/>) only recommends that,
|
||||
besides the group <systemitem class="groupname">root</systemitem> with a
|
||||
Group ID (GID) of 0, a group <systemitem class="groupname">bin</systemitem>
|
||||
with a GID of 1 be present. The GID of 5 is widely used for
|
||||
with a GID of 1 be present. The GID of 5 is widely used for the
|
||||
<systemitem class="groupname">tty</systemitem> group, and the number 5 is
|
||||
also used in <phrase revision="systemd">systemd</phrase>
|
||||
<phrase revision="sysv"><filename>/etc/fstab</filename></phrase> for the
|
||||
@ -179,7 +179,7 @@ EOF</userinput></screen>
|
||||
or the parent user namespace, but <quote>do not exist</quote> on the local
|
||||
machine or in the separate namespace). We assign
|
||||
<systemitem class="username">nobody</systemitem> and
|
||||
<systemitem class="groupname">nogroup</systemitem> for it to avoid an
|
||||
<systemitem class="groupname">nogroup</systemitem> to avoid an
|
||||
unnamed ID. But other distros may treat this ID differently, so any
|
||||
portable program should not depend on this assignment.</para>
|
||||
|
||||
|
@ -15,13 +15,13 @@
|
||||
</indexterm>
|
||||
|
||||
<para>Applications running in user space utilize various file
|
||||
systems exported by the kernel to communicate
|
||||
systems created by the kernel to communicate
|
||||
with the kernel itself. These file systems are virtual: no disk
|
||||
space is used for them. The content of the file systems resides in
|
||||
space is used for them. The content of these file systems resides in
|
||||
memory. These file systems must be mounted in the $LFS directory tree
|
||||
so the applications can find them in the chroot environment.</para>
|
||||
|
||||
<para>Begin by creating directories on which the file systems will be
|
||||
<para>Begin by creating the directories on which these virtual file systems will be
|
||||
mounted:</para>
|
||||
|
||||
<screen><userinput>mkdir -pv $LFS/{dev,proc,sys,run}</userinput></screen>
|
||||
@ -29,31 +29,30 @@
|
||||
<sect2 id="ch-tools-bindmount">
|
||||
<title>Mounting and Populating /dev</title>
|
||||
|
||||
<para>During a normal boot of the LFS system, the kernel automatically
|
||||
<para>During a normal boot of an LFS system, the kernel automatically
|
||||
mounts the <systemitem class="filesystem">devtmpfs</systemitem>
|
||||
filesystem on the
|
||||
file system on the
|
||||
<filename class="directory">/dev</filename> directory; the kernel
|
||||
creates device nodes on that virtual filesystem during the boot process
|
||||
creates device nodes on that virtual file system during the boot process,
|
||||
or when a device is first detected or accessed. The udev daemon may
|
||||
change the owner or permission of the device nodes created by the
|
||||
kernel, or create new device nodes or symlinks to ease the work of
|
||||
distro maintainers or system administrators. (See
|
||||
change the ownership or permissions of the device nodes created by the
|
||||
kernel, and create new device nodes or symlinks, to ease the work of
|
||||
distro maintainers and system administrators. (See
|
||||
<xref linkend='ch-config-udev-device-node-creation'/> for details.)
|
||||
If the host kernel supports &devtmpfs;, we can simply mount a
|
||||
&devtmpfs; at <filename class='directory'>$LFS/dev</filename> and rely
|
||||
on the kernel to populate it (the LFS building process does not need
|
||||
the additional work onto &devtmpfs; by udev daemon).</para>
|
||||
on the kernel to populate it.</para>
|
||||
|
||||
<para>But, some host kernels may lack &devtmpfs; support and these
|
||||
host distros maintain the content of
|
||||
<filename class="directory">/dev</filename> with different methods.
|
||||
So the only host-agnostic way for populating
|
||||
<filename class="directory">$LFS/dev</filename> is
|
||||
bind mounting the host system's
|
||||
<para>But some host kernels lack &devtmpfs; support; these
|
||||
host distros use different methods to create the content of
|
||||
<filename class="directory">/dev</filename>.
|
||||
So the only host-agnostic way to populate the
|
||||
<filename class="directory">$LFS/dev</filename> directory is
|
||||
by bind mounting the host system's
|
||||
<filename class="directory">/dev</filename> directory. A bind mount is
|
||||
a special type of mount that allows you to create a mirror of a
|
||||
directory or mount point at some other location. Use the following
|
||||
command to do this:</para>
|
||||
a special type of mount that makes a directory subtree or a file
|
||||
visible at some other location. Use the following
|
||||
command to do this.</para>
|
||||
|
||||
<screen><userinput>mount -v --bind /dev $LFS/dev</userinput></screen>
|
||||
|
||||
@ -62,7 +61,7 @@
|
||||
<sect2 id="ch-tools-kernfsmount">
|
||||
<title>Mounting Virtual Kernel File Systems</title>
|
||||
|
||||
<para>Now mount the remaining virtual kernel filesystems:</para>
|
||||
<para>Now mount the remaining virtual kernel file systems:</para>
|
||||
|
||||
<screen><userinput>mount -v --bind /dev/pts $LFS/dev/pts
|
||||
mount -vt proc proc $LFS/proc
|
||||
|
@ -59,7 +59,7 @@
|
||||
<term><parameter>-G</parameter></term>
|
||||
<listitem>
|
||||
<para>Omit parts of the test suite that won't work
|
||||
without a GNU bc present.</para>
|
||||
until the bc program has been installed.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
@ -87,7 +87,7 @@ cd build</userinput></screen>
|
||||
<varlistentry>
|
||||
<term><parameter>--enable-gold</parameter></term>
|
||||
<listitem>
|
||||
<para>Build the gold linker and install it as ld.gold (along side the
|
||||
<para>Build the gold linker and install it as ld.gold (alongside the
|
||||
default linker).</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -118,7 +118,7 @@ cd build</userinput></screen>
|
||||
<varlistentry>
|
||||
<term><parameter>--with-system-zlib</parameter></term>
|
||||
<listitem>
|
||||
<para>Use the installed zlib library rather than building the
|
||||
<para>Use the installed zlib library instead of building the
|
||||
included version.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -143,7 +143,7 @@ cd build</userinput></screen>
|
||||
a custom system, this target-specific directory in <filename
|
||||
class="directory">/usr</filename> is not required. <filename
|
||||
class="directory">$(exec_prefix)/$(target_alias)</filename> would be
|
||||
used if the system was used to cross-compile (for example, compiling a
|
||||
used if the system were used to cross-compile (for example, compiling a
|
||||
package on an Intel machine that generates code that can be executed
|
||||
on PowerPC machines).</para>
|
||||
</listitem>
|
||||
@ -177,8 +177,8 @@ cd build</userinput></screen>
|
||||
some gas tests may fail if parallel jobs are used. If you are not
|
||||
assured of the correctness of gas, invoke
|
||||
<command>make check-gas</command> to run gas testsuite separately and
|
||||
all tests should pass. Three gprofng tests result
|
||||
<literal>ERROR</literal> and they are counted as
|
||||
all tests should pass. Three gprofng tests yield the
|
||||
<literal>ERROR</literal> result, and they are counted as
|
||||
<literal>UNRESOLVED</literal> in the summary.</para>
|
||||
|
||||
<para>Install the package:</para>
|
||||
@ -271,7 +271,7 @@ rm -fv /usr/share/man/man1/gprofng.1</userinput></screen>
|
||||
<varlistentry id="elfedit">
|
||||
<term><command>elfedit</command></term>
|
||||
<listitem>
|
||||
<para>Updates the ELF header of ELF files</para>
|
||||
<para>Updates the ELF headers of ELF files</para>
|
||||
<indexterm zone="ch-system-binutils elfedit">
|
||||
<primary sortas="b-elfedit">elfedit</primary>
|
||||
</indexterm>
|
||||
@ -291,7 +291,7 @@ rm -fv /usr/share/man/man1/gprofng.1</userinput></screen>
|
||||
<varlistentry id="gprofng">
|
||||
<term><command>gprofng</command></term>
|
||||
<listitem>
|
||||
<para>Gather and analyze performance data</para>
|
||||
<para>Gathers and analyzes performance data</para>
|
||||
<indexterm zone="ch-system-binutils gprofng">
|
||||
<primary sortas="b-gprofng">gprofng</primary>
|
||||
</indexterm>
|
||||
@ -324,7 +324,7 @@ rm -fv /usr/share/man/man1/gprofng.1</userinput></screen>
|
||||
<varlistentry id="ld.bfd">
|
||||
<term><command>ld.bfd</command></term>
|
||||
<listitem>
|
||||
<para>Hard link to <command>ld</command></para>
|
||||
<para>A hard link to <command>ld</command></para>
|
||||
<indexterm zone="ch-system-binutils ld.bfd">
|
||||
<primary sortas="b-ld.bfd">ld.bfd</primary>
|
||||
</indexterm>
|
||||
|
@ -43,7 +43,7 @@
|
||||
<sect2 role="installation">
|
||||
<title>Installation of Glibc</title>
|
||||
|
||||
<para>First, fix an issue building Glibc with parallel jobs and make-4.4
|
||||
<para>First, fix an issue building Glibc with parallel jobs and Make-4.4
|
||||
or later:</para>
|
||||
|
||||
<screen><userinput remap="pre">sed '/MAKEFLAGS :=/s/)r/) -r/' -i Makerules</userinput></screen>
|
||||
@ -90,7 +90,7 @@ cd build</userinput></screen>
|
||||
<varlistentry>
|
||||
<term><parameter>--enable-kernel=&min-kernel;</parameter></term>
|
||||
<listitem>
|
||||
<para>This option tells the build system that this glibc may
|
||||
<para>This option tells the build system that this Glibc may
|
||||
be used with kernels as old as &min-kernel;. This means generating
|
||||
workarounds in case a system call introduced in a later version
|
||||
cannot be used.</para>
|
||||
@ -217,7 +217,7 @@ esac</userinput></screen>
|
||||
|
||||
<screen><userinput remap="install">make install</userinput></screen>
|
||||
|
||||
<para>Fix hardcoded path to the executable loader in
|
||||
<para>Fix a hardcoded path to the executable loader in the
|
||||
<command>ldd</command> script:</para>
|
||||
|
||||
<screen><userinput remap="install">sed '/RTLDLIST=/s@/usr@@g' -i /usr/bin/ldd</userinput></screen>
|
||||
@ -235,9 +235,9 @@ mkdir -pv /var/cache/nscd</userinput></screen>
|
||||
install -v -Dm644 ../nscd/nscd.service /usr/lib/systemd/system/nscd.service</userinput></screen>
|
||||
|
||||
<para>Next, install the locales that can make the system respond in a
|
||||
different language. None of the locales are required, but if some of them
|
||||
are missing, the test suites of future packages would skip important
|
||||
testcases.</para>
|
||||
different language. None of these locales are required, but if some of them
|
||||
are missing, the test suites of some packages will skip important
|
||||
test cases.</para>
|
||||
|
||||
<para>Individual locales can be installed using the
|
||||
<command>localedef</command> program. E.g., the second
|
||||
@ -290,7 +290,7 @@ localedef -i zh_TW -f UTF-8 zh_TW.UTF-8</userinput></screen>
|
||||
<para>In addition, install the locale for your own country, language and
|
||||
character set.</para>
|
||||
|
||||
<para>Alternatively, install all locales listed in the
|
||||
<para>Alternatively, install all the locales listed in the
|
||||
<filename>glibc-&glibc-version;/localedata/SUPPORTED</filename> file
|
||||
(it includes every locale listed above and many more) at once with the
|
||||
following time-consuming command:</para>
|
||||
@ -356,7 +356,7 @@ EOF</userinput></screen>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Adding time zone data</title>
|
||||
<title>Adding Time Zone Data</title>
|
||||
|
||||
<para>Install and set up the time zone data with the following:</para>
|
||||
<screen><userinput>tar -xf ../../tzdata&tzdata-version;.tar.gz
|
||||
|
@ -20,20 +20,28 @@
|
||||
work is to know what each package is used for and why you (or the system)
|
||||
may need it.</para>
|
||||
|
||||
<para>We do not recommend using optimizations. They can make
|
||||
<para>We do not recommend using customized optimizations. They can make
|
||||
a program run slightly faster, but they may also cause compilation
|
||||
difficulties and problems when running the program. If a package refuses to
|
||||
compile when using optimization, try to compile it without optimization and
|
||||
see if that fixes the problem. Even if the package does compile when using
|
||||
difficulties, and problems when running the program. If a package refuses to
|
||||
compile with a customized optimization, try to compile it without
|
||||
optimization and see if that fixes the problem. Even if the package does compile when using a customized
|
||||
optimization, there is the risk it may have been compiled incorrectly because
|
||||
of the complex interactions between the code and build tools. Also note that
|
||||
of the complex interactions between the code and the build tools. Also note that
|
||||
the <option>-march</option> and <option>-mtune</option> options using values
|
||||
not specified in the book have not been tested. This may cause problems with
|
||||
the toolchain packages (Binutils, GCC and Glibc). The small potential gains
|
||||
achieved in using compiler optimizations are often outweighed by the risks.
|
||||
achieved by customizing compiler optimizations are often outweighed by the risks.
|
||||
First-time builders of LFS are encouraged to build without custom
|
||||
optimizations. The subsequent system will still run very fast and be stable
|
||||
at the same time.</para>
|
||||
optimizations.</para>
|
||||
|
||||
<para>On the other hand, we keep the optimizations enabled by the default
|
||||
configuration of the packages. In addition, we sometimes explicitly enable an
|
||||
optimized configuration provided by a package but not enabled by
|
||||
default. The package maintainers have already tested these configurations
|
||||
and consider them safe, so it's not likely they would break the build.
|
||||
Generally the default configuration already enables <option>-O2</option>
|
||||
or <option>-O3</option>, so the resulting system will still run very fast
|
||||
without any customized optimization, and be stable at the same time.</para>
|
||||
|
||||
<para>Before the installation instructions, each installation page provides
|
||||
information about the package, including a concise description of what it
|
||||
@ -42,31 +50,31 @@
|
||||
instructions, there is a list of programs and libraries (along with brief
|
||||
descriptions) that the package installs.</para>
|
||||
|
||||
<note><para>The SBU values and required disk space includes test suite data
|
||||
<note><para>The SBU values and required disk space include test suite data
|
||||
for all applicable packages in <xref linkend="chapter-building-system"/>. SBU
|
||||
values have been calculated using a single CPU core (-j1) for all
|
||||
operations.</para></note>
|
||||
|
||||
<sect2>
|
||||
<title>About libraries</title>
|
||||
<title>About Libraries</title>
|
||||
|
||||
<para>In general, the LFS editors discourage building and installing static
|
||||
libraries. The original purpose for most static libraries has been made
|
||||
libraries. Most static libraries have been made
|
||||
obsolete in a modern Linux system. In addition, linking a static library
|
||||
into a program can be detrimental. If an update to the library is needed
|
||||
to remove a security problem, all programs that use the static library will
|
||||
need to be relinked to the new library. Since the use of static libraries
|
||||
to remove a security problem, every program that uses the static library will
|
||||
need to be relinked with the new library. Since the use of static libraries
|
||||
is not always obvious, the relevant programs (and the procedures needed to
|
||||
do the linking) may not even be known.</para>
|
||||
|
||||
<para>In the procedures in this chapter, we remove or disable installation of
|
||||
<para>The procedures in this chapter remove or disable installation of
|
||||
most static libraries. Usually this is done by passing a
|
||||
<option>--disable-static</option> option to <command>configure</command>.
|
||||
In other cases, alternate means are needed. In a few cases, especially
|
||||
glibc and gcc, the use of static libraries remains essential to the general
|
||||
Glibc and GCC, the use of static libraries remains an essential feature of the
|
||||
package building process. </para>
|
||||
|
||||
<para>For a more complete discussion of libraries, see the discussion
|
||||
<para>For a more complete discussion of libraries, see
|
||||
<ulink url="&blfs-book;introduction/libraries.html">
|
||||
Libraries: Static or shared?</ulink> in the BLFS book.</para>
|
||||
|
||||
|
@ -12,10 +12,11 @@
|
||||
|
||||
<para>Package Management is an often requested addition to the LFS Book. A
|
||||
Package Manager tracks the installation of files, making it easier to
|
||||
remove and upgrade packages. As well as the binary and library files, a
|
||||
package manager will handle the installation of configuration files. Before
|
||||
remove and upgrade packages. A good package manager will also handle the
|
||||
configuration files specially to keep the user configuration when the
|
||||
package is reinstalled or upgraded. Before
|
||||
you begin to wonder, NO—this section will not talk about nor recommend
|
||||
any particular package manager. What it provides is a roundup of the more
|
||||
any particular package manager. What it does provide is a roundup of the more
|
||||
popular techniques and how they work. The perfect package manager for you may
|
||||
be among these techniques, or it may be a combination of two or more of these
|
||||
techniques. This section briefly mentions issues that may arise when upgrading
|
||||
@ -61,8 +62,8 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If Linux API headers or glibc need to be upgraded to a newer
|
||||
version, (e.g., from glibc-2.31 to glibc-2.32), it is safer to
|
||||
<para>If the Linux API headers or Glibc need to be upgraded to a newer
|
||||
version, (e.g., from Glibc-2.31 to Glibc-2.32), it is safer to
|
||||
rebuild LFS. Though you <emphasis>may</emphasis> be able to rebuild
|
||||
all the packages in their dependency order, we do not recommend
|
||||
it. </para>
|
||||
@ -202,7 +203,7 @@
|
||||
it is installed in <filename class="directory">/usr</filename> though in
|
||||
reality it is installed in the
|
||||
<filename class="directory">/usr/pkg</filename> hierarchy. Installing in
|
||||
this manner is not usually a trivial task. For example, consider that you
|
||||
this manner is not usually a trivial task. For example, suppose you
|
||||
are installing a package libfoo-1.1. The following instructions may
|
||||
not install the package properly:</para>
|
||||
|
||||
@ -321,7 +322,8 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
|
||||
depend on the position of files on a disk system. Cloning an LFS build to
|
||||
another computer with the same architecture as the base system is as
|
||||
simple as using <command>tar</command> on the LFS partition that contains
|
||||
the root directory (about 250MB uncompressed for a base LFS build), copying
|
||||
the root directory (about 900MB uncompressed for a basic LFS build), copying
|
||||
<!-- D. Bryant created LFS 11.2 in October 2022; 900MB is (roughly) the size of his rsync archive. -->
|
||||
that file via network transfer or CD-ROM / USB stick to the new system, and expanding
|
||||
it. After that, a few configuration files will have to be changed.
|
||||
Configuration files that may need to be updated include:
|
||||
|
@ -23,7 +23,7 @@
|
||||
<sect2 role="package">
|
||||
<title/>
|
||||
|
||||
<para>The Readline package is a set of libraries that offers command-line
|
||||
<para>The Readline package is a set of libraries that offer command-line
|
||||
editing and history capabilities.</para>
|
||||
|
||||
<segmentedlist>
|
||||
@ -61,14 +61,14 @@ sed -i '/{OLDSUFF}/c:' support/shlib-install</userinput></screen>
|
||||
--docdir=/usr/share/doc/readline-&readline-version;</userinput></screen>
|
||||
|
||||
<variablelist>
|
||||
<title>The meaning of the configure option:</title>
|
||||
<title>The meaning of the new configure option:</title>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--with-curses</parameter></term>
|
||||
<listitem>
|
||||
<para>This option tells Readline that it can find the termcap
|
||||
library functions in the curses library, rather than a separate
|
||||
termcap library. It allows generating a correct
|
||||
library functions in the curses library, not a separate
|
||||
termcap library. This will generate the correct
|
||||
<filename>readline.pc</filename> file.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -244,7 +244,7 @@ useradd -D --gid 999</userinput></screen>
|
||||
|
||||
<segmentedlist>
|
||||
<segtitle>Installed programs</segtitle>
|
||||
<segtitle>Installed directory</segtitle>
|
||||
<segtitle>Installed directories</segtitle>
|
||||
<segtitle>Installed libraries</segtitle>
|
||||
|
||||
<seglistitem>
|
||||
@ -254,7 +254,7 @@ useradd -D --gid 999</userinput></screen>
|
||||
newuidmap, newusers, nologin, passwd, pwck, pwconv, pwunconv,
|
||||
sg (link to newgrp), su, useradd, userdel, usermod,
|
||||
vigr (link to vipw), and vipw</seg>
|
||||
<seg>/etc/default</seg>
|
||||
<seg>/etc/default and /usr/include/shadow</seg>
|
||||
<seg>libsubid.so</seg>
|
||||
</seglistitem>
|
||||
</segmentedlist>
|
||||
|
@ -27,7 +27,7 @@
|
||||
|
||||
<para>The <application>Tcl</application> package contains the Tool Command Language,
|
||||
a robust general-purpose scripting language. The <application>Expect</application> package
|
||||
is written in the <application>Tcl</application> language.</para>
|
||||
is written in <application>Tcl</application> (pronounced "tickle").</para>
|
||||
|
||||
<segmentedlist>
|
||||
<segtitle>&buildtime;</segtitle>
|
||||
@ -45,7 +45,7 @@
|
||||
<title>Installation of Tcl</title>
|
||||
|
||||
<para>This package and the next two (Expect and DejaGNU) are
|
||||
installed to support running the test suites for binutils and GCC and other
|
||||
installed to support running the test suites for Binutils, GCC and other
|
||||
packages. Installing three packages for testing purposes may seem
|
||||
excessive, but it is very reassuring, if not essential, to know that the
|
||||
most important tools are working properly.</para>
|
||||
@ -87,9 +87,9 @@ sed -e "s|$SRCDIR/unix/pkgs/itcl&itcl-ver;|/usr/lib/itcl&itcl-ver;|" \
|
||||
unset SRCDIR</userinput></screen>
|
||||
|
||||
<para>The various <quote>sed</quote> instructions after the
|
||||
<quote>make</quote> command removes references to the build directory from
|
||||
the configuration files and replaces them with the install directory.
|
||||
This is not mandatory for the remainder of LFS, but may be needed in case a
|
||||
<quote>make</quote> command remove references to the build directory from
|
||||
the configuration files and replace them with the install directory.
|
||||
This is not mandatory for the remainder of LFS, but may be needed if a
|
||||
package built later uses Tcl.</para>
|
||||
|
||||
<para>To test the results, issue:</para>
|
||||
|
@ -48,7 +48,6 @@
|
||||
--bindir=/usr/bin \
|
||||
--libdir=/usr/lib \
|
||||
--sbindir=/usr/sbin \
|
||||
--docdir=/usr/share/doc/util-linux-&util-linux-version; \
|
||||
--disable-chfn-chsh \
|
||||
--disable-login \
|
||||
--disable-nologin \
|
||||
@ -59,13 +58,13 @@
|
||||
--disable-static \
|
||||
--without-python \
|
||||
--without-systemd \
|
||||
--without-systemdsystemunitdir</userinput></screen>
|
||||
--without-systemdsystemunitdir \
|
||||
--docdir=/usr/share/doc/util-linux-&util-linux-version;</userinput></screen>
|
||||
|
||||
<screen revision="systemd"><userinput remap="configure">./configure ADJTIME_PATH=/var/lib/hwclock/adjtime \
|
||||
--bindir=/usr/bin \
|
||||
--libdir=/usr/lib \
|
||||
--sbindir=/usr/sbin \
|
||||
--docdir=/usr/share/doc/util-linux-&util-linux-version; \
|
||||
--disable-chfn-chsh \
|
||||
--disable-login \
|
||||
--disable-nologin \
|
||||
@ -74,7 +73,8 @@
|
||||
--disable-runuser \
|
||||
--disable-pylibmount \
|
||||
--disable-static \
|
||||
--without-python</userinput></screen>
|
||||
--without-python \
|
||||
--docdir=/usr/share/doc/util-linux-&util-linux-version;</userinput></screen>
|
||||
|
||||
<para>The --disable and --without options prevent warnings about
|
||||
building components that require packages not in LFS or are
|
||||
|
@ -139,6 +139,7 @@ if ( $package == "procps-ng" ) $dirpath = "https://gitlab.com/procps-ng/procps/
|
||||
if ( $package == "psmisc" ) $dirpath = "https://gitlab.com/psmisc/psmisc/-/tags";
|
||||
if ( $package == "Python" ) $dirpath = "https://www.python.org/downloads/source/";
|
||||
if ( $package == "shadow" ) $dirpath = "https://github.com/shadow-maint/shadow/releases";
|
||||
if ( $package == "sysvinit" ) $dirpath = "https://github.com/slicer69/sysvinit/releases";
|
||||
if ( $package == "MarkupSafe" ) $dirpath = "https://pypi.python.org/pypi/MarkupSafe/";
|
||||
if ( $package == "Jinja" ) $dirpath = "https://pypi.python.org/pypi/Jinja2/";
|
||||
if ( $package == "systemd" ) $dirpath = "https://github.com/systemd/systemd/releases";
|
||||
@ -275,6 +276,9 @@ if ( $package == "zstd" ) $dirpath = "https://github.com/facebook/zstd/rel
|
||||
if ( $package == "shadow" )
|
||||
return find_max( $lines, "/^\s+\d\./", "/^\s+([\d\.]+)$/" );
|
||||
|
||||
if ( $package == "sysvinit" )
|
||||
return find_max( $lines, "/^\s+\d\./", "/^\s+([\d\.]+)$/" );
|
||||
|
||||
if ( $package == "XML-Parser" )
|
||||
{
|
||||
$max = find_max( $lines, "/$package/", "/^.*$package-([\d\._]*\d).tar.*$/" );
|
||||
|
@ -352,7 +352,7 @@
|
||||
|
||||
<!ENTITY jinja2-version "3.1.2">
|
||||
<!ENTITY jinja2-size "262 KB">
|
||||
<!ENTITY jinja2-url "https://files.pythonhosted.org/packages/source/J/Jinja2/Jinja2-&jinja2-version;.tar.gz">
|
||||
<!ENTITY jinja2-url "&pypi-src;/J/Jinja2/Jinja2-&jinja2-version;.tar.gz">
|
||||
<!ENTITY jinja2-md5 "d31148abd89c1df1cdb077a55db27d02">
|
||||
<!ENTITY jinja2-home "https://jinja.palletsprojects.com/en/3.0.x/">
|
||||
<!ENTITY jinja2-fin-du "3.0 MB">
|
||||
@ -481,7 +481,7 @@
|
||||
|
||||
<!ENTITY markupsafe-version "2.1.1">
|
||||
<!ENTITY markupsafe-size "20 KB">
|
||||
<!ENTITY markupsafe-url "https://files.pythonhosted.org/packages/source/M/MarkupSafe/MarkupSafe-&markupsafe-version;.tar.gz">
|
||||
<!ENTITY markupsafe-url "&pypi-src;/M/MarkupSafe/MarkupSafe-&markupsafe-version;.tar.gz">
|
||||
<!ENTITY markupsafe-md5 "9809f9fdd98bc835b0c21aa8f79cbf30">
|
||||
<!ENTITY markupsafe-home "https://palletsprojects.com/p/markupsafe/">
|
||||
<!ENTITY markupsafe-fin-du "168 KB">
|
||||
|
Loading…
Reference in New Issue
Block a user