Changeset dd61c77
- Timestamp:
- 10/01/2022 08:03:20 AM (18 months ago)
- Branches:
- xry111/clfs-ng
- Children:
- ef1f48b
- Parents:
- 259794e (diff), 2bf32ff (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the(diff)
links above to see all the changes relative to each parent. - Files:
-
- 18 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter01/changelog.xml
r259794e rdd61c77 40 40 appropriate for the entry or if needed the entire day's listitem. 41 41 --> 42 43 <listitem> 44 <para>2022-10-01</para> 45 <itemizedlist> 46 <listitem> 47 <para>[bdubbs] - Update to iana-etc-20220922. Addresses 48 <ulink url="&lfs-ticket-root;5006">#5006</ulink>.</para> 49 </listitem> 50 <listitem> 51 <para>[bdubbs] - Update to tzdata-2022d. Fixes 52 <ulink url="&lfs-ticket-root;5119">#5119</ulink>.</para> 53 </listitem> 54 <listitem> 55 <para>[bdubbs] - Update to readline-8.2. Fixes 56 <ulink url="&lfs-ticket-root;5121">#5121</ulink>.</para> 57 </listitem> 58 <listitem> 59 <para>[bdubbs] - Update to linux-5.19.12. Fixes 60 <ulink url="&lfs-ticket-root;5115">#5115</ulink>.</para> 61 </listitem> 62 <listitem> 63 <para>[bdubbs] - Update to libffi-3.4.3. Fixes 64 <ulink url="&lfs-ticket-root;5116">#5116</ulink>.</para> 65 </listitem> 66 <listitem> 67 <para>[bdubbs] - Update to libcap-2.66. Fixes 68 <ulink url="&lfs-ticket-root;512">#5120</ulink>.</para> 69 </listitem> 70 <listitem revision="systemd"> 71 <para>[bdubbs] - Update to dbus-1.14.2. Fixes 72 <ulink url="&lfs-ticket-root;5123">#5123</ulink>.</para> 73 </listitem> 74 <listitem> 75 <para>[bdubbs] - Update to bc-6.0.4. Fixes 76 <ulink url="&lfs-ticket-root;5114">#5114</ulink>.</para> 77 </listitem> 78 <listitem> 79 <para>[bdubbs] - Update to bash-5.2. Fixes 80 <ulink url="&lfs-ticket-root;5122">#5122</ulink>.</para> 81 </listitem> 82 </itemizedlist> 83 </listitem> 42 84 43 85 <listitem> -
chapter01/whatsnew.xml
r259794e rdd61c77 12 12 <title>What's new since the last release</title> 13 13 14 <para>In 11.3 release, <parameter>--enable-default-pie</parameter> 15 and <parameter>--enable-default-ssp</parameter> are enabled for GCC. 16 They can mitigate some type of malicious attacks but they cannot provide 17 a full protection. In case if you are reading a programming textbook, 18 you may need to disable PIE and SSP with GCC options 19 <parameter>-fno-pie -no-pie -fno-stack-protection</parameter> 20 because some textbooks assume they were disabled by default.</para> 21 14 22 <para>Below is a list of package updates made since the previous 15 23 release of the book.</para> … … 39 47 <para>Automake-&automake-version;</para> 40 48 </listitem>--> 41 < !--<listitem>49 <listitem> 42 50 <para>Bash &bash-version;</para> 43 </listitem> -->51 </listitem> 44 52 <listitem> 45 53 <para>Bc &bc-version;</para> … … 63 71 <para>DejaGNU-&dejagnu-version;</para> 64 72 </listitem>--> 65 < !--<listitem revision="systemd">73 <listitem revision="systemd"> 66 74 <para>D-Bus-&dbus-version;</para> 67 </listitem> -->75 </listitem> 68 76 <!--<listitem> 69 77 <para>Diffutils-&diffutils-version;</para> … … 123 131 <para>Gzip-&gzip-version;</para> 124 132 </listitem>--> 125 < !--<listitem>133 <listitem> 126 134 <para>IANA-Etc-&iana-etc-version;</para> 127 </listitem>-->135 </listitem> 128 136 <!--<listitem> 129 137 <para>Inetutils-&inetutils-version;</para> … … 150 158 <para>LFS-Bootscripts-&lfs-bootscripts-version;</para> 151 159 </listitem>--> 152 < !--<listitem>160 <listitem> 153 161 <para>Libcap-&libcap-version;</para> 154 </listitem> -->162 </listitem> 155 163 <!--<listitem> 156 164 <para>Libelf-&elfutils-version; (from elfutils)</para> 157 165 </listitem>--> 158 < !--<listitem>166 <listitem> 159 167 <para>Libffi-&libffi-version;</para> 160 </listitem> -->168 </listitem> 161 169 <!--<listitem> 162 170 <para>Libpipeline-&libpipeline-version;</para> … … 219 227 <para>Python-&python-version;</para> 220 228 </listitem> 221 < !--<listitem>229 <listitem> 222 230 <para>Readline-&readline-version;</para> 223 </listitem> -->231 </listitem> 224 232 <!--<listitem> 225 233 <para>Sed-&sed-version;</para> … … 246 254 <para>Texinfo-&texinfo-version;</para> 247 255 </listitem>--> 248 < !--<listitem>256 <listitem> 249 257 <para>Tzdata-&tzdata-version;</para> 250 </listitem> -->258 </listitem> 251 259 <!--<listitem> 252 260 <para>Util-Linux-&util-linux-version;</para> -
chapter02/mounting.xml
r259794e rdd61c77 16 16 <envar>LFS</envar> environment variable described in the previous section. 17 17 </para> 18 19 <para>Strictly speaking, one cannot "mount a partition". One mounts the <emphasis>file 20 system</emphasis> embedded in that partition. But since a single partition can't contain 21 more than one file system, people often speak of the partition and the 22 associated file system as if they were one and the same.</para> 18 23 19 24 <para>Create the mount point and mount the LFS file system with these commands:</para> -
chapter04/aboutsbus.xml
r259794e rdd61c77 14 14 it takes to compile and install each package. Because Linux From 15 15 Scratch can be built on many different systems, it is impossible to 16 provide a ccurate time estimates. The biggest package (Glibc) will16 provide absolute time estimates. The biggest package (Glibc) will 17 17 take approximately 20 minutes on the fastest systems, but could take 18 18 up to three days on slower systems! Instead of providing actual times, … … 21 21 22 22 <para>The SBU measure works as follows. The first package to be compiled 23 from this bookis binutils in <xref linkend="chapter-cross-tools"/>. The24 time it takes to compile this package is what w ill be referredto as the25 Standard Build Unit or SBU. All other compile times will be expressed relative26 t o thistime.</para>23 is binutils in <xref linkend="chapter-cross-tools"/>. The 24 time it takes to compile this package is what we will refer to as the 25 Standard Build Unit or SBU. All other compile times will be expressed in 26 terms of this unit of time.</para> 27 27 28 28 <para>For example, consider a package whose compilation time is 4.5 29 SBUs. This means that if asystem took 10 minutes to compile and29 SBUs. This means that if your system took 10 minutes to compile and 30 30 install the first pass of binutils, it will take 31 <emphasis>approximately</emphasis> 45 minutes to build th isexample package.32 Fortunately, most build times are shorter than the one for binutils.</para>31 <emphasis>approximately</emphasis> 45 minutes to build the example package. 32 Fortunately, most build times are shorter than one SBU.</para> 33 33 34 <para> In general,SBUs are not entirely accurate because they depend on many34 <para>SBUs are not entirely accurate because they depend on many 35 35 factors, including the host system's version of GCC. They are provided here 36 36 to give an estimate of how long it might take to install a package, but the … … 54 54 <screen role="nodump"><userinput>export MAKEFLAGS='-j4'</userinput></screen> 55 55 56 <para>or justbuilding with:</para>56 <para>or by building with:</para> 57 57 58 58 <screen role="nodump"><userinput>make -j4</userinput></screen> … … 61 61 book will vary even more than they normally would. In some cases, the make 62 62 step will simply fail. Analyzing the output of the build process will also 63 be more difficult because the lines ofdifferent processes will be64 interleaved. If you run into a problem with a build step, revert backto a63 be more difficult because the lines from different processes will be 64 interleaved. If you run into a problem with a build step, revert to a 65 65 single processor build to properly analyze the error messages.</para> 66 66 </note> -
chapter04/abouttestsuites.xml
r259794e rdd61c77 28 28 <para>Running the test suites in <xref linkend="chapter-cross-tools"/> 29 29 and <xref linkend="chapter-temporary-tools"/> 30 is impossible, since theprograms are compiled with a cross-compiler,31 so are not supposed to be able torun on the build host.</para>30 is pointless; since the test programs are compiled with a cross-compiler, 31 they probably can't run on the build host.</para> 32 32 </note> 33 33 34 34 <para>A common issue with running the test suites for binutils and GCC 35 is running out of pseudo terminals (PTYs). This can result in a high35 is running out of pseudo terminals (PTYs). This can result in a large 36 36 number of failing tests. This may happen for several reasons, but the 37 37 most likely cause is that the host system does not have the … … 40 40 <ulink url="&lfs-root;lfs/faq.html#no-ptys"/>.</para> 41 41 42 <para>Sometimes package test suites will fail , butfor reasons which the42 <para>Sometimes package test suites will fail for reasons which the 43 43 developers are aware of and have deemed non-critical. Consult the logs located 44 44 at <ulink url="&test-results;"/> to verify whether or not these failures are 45 expected. This site is valid for all test s throughout this book.</para>45 expected. This site is valid for all test suites throughout this book.</para> 46 46 47 47 </sect1> -
chapter04/addinguser.xml
r259794e rdd61c77 15 15 the packages in the next two chapters are built as an unprivileged user. 16 16 You could use your own user name, but to make it easier to set up a clean 17 working environment, create a new user called <systemitem17 working environment, we will create a new user called <systemitem 18 18 class="username">lfs</systemitem> as a member of a new group (also named 19 <systemitem class="groupname">lfs</systemitem>) and use this userduring19 <systemitem class="groupname">lfs</systemitem>) and run commands as &lfs-user; during 20 20 the installation process. As <systemitem class="username">root</systemitem>, 21 21 issue the following commands to add the new user:</para> … … 25 25 26 26 <variablelist> 27 <title>Th e meaning of the command line options:</title>27 <title>This is what the command line options mean:</title> 28 28 29 29 <varlistentry> … … 55 55 <listitem> 56 56 <para>This parameter prevents possible copying of files from a skeleton 57 directory ( default is <filename class="directory">/etc/skel</filename>)57 directory (the default is <filename class="directory">/etc/skel</filename>) 58 58 by changing the input location to the special null device.</para> 59 59 </listitem> … … 69 69 </variablelist> 70 70 71 <para> To log in as <systemitem class="username">lfs</systemitem> (as opposed72 to switching to user <systemitem class="username">lfs</systemitem> when logged73 in as <systemitem class="username">root</systemitem>, which does not require74 the <systemitem class="username">lfs</systemitem> user to have a password),75 give <systemitem class="username">lfs</systemitem> apassword:</para>71 <para>If you want to log in as &lfs-user; or switch to &lfs-user; from a 72 non-&root; user (as opposed to switching to user &lfs-user; 73 when logged in as &root;, which does not require the &lfs-user; user to 74 have a password), you need to set a password of &lfs-user;. Issue the 75 following command as the &root; user to set the password:</para> 76 76 77 77 <screen role="nodump"><userinput>passwd lfs</userinput></screen> 78 78 79 79 <para>Grant <systemitem class="username">lfs</systemitem> full access to 80 all directories under <filename class="directory">$LFS</filename> by making81 <systemitem class="username">lfs</systemitem> the directoryowner:</para>80 all the directories under <filename class="directory">$LFS</filename> by making 81 <systemitem class="username">lfs</systemitem> the owner:</para> 82 82 83 83 <screen><userinput>chown -v lfs $LFS/{usr{,/*},lib*,boot,var,etc,bin,sbin,tools}</userinput></screen> 84 84 85 <note><para>In some host systems, the followingcommand does not complete86 properly and suspends the login tothe &lfs-user; user to the background.85 <note><para>In some host systems, the following <command>su</command> command does not complete 86 properly and suspends the login for the &lfs-user; user to the background. 87 87 If the prompt "lfs:~$" does not appear immediately, entering the 88 88 <command>fg</command> command will fix the issue.</para></note> 89 89 90 <para>Next, login as user <systemitem class="username">lfs</systemitem>.91 This can be done via a virtual console, through a display manager, or with92 the followingsubstitute/switch user command:</para>90 <para>Next, start a shell running as user &lfs-user;. This can be done by 91 logging in as &lfs-user; on a virtual console, or with the following 92 substitute/switch user command:</para> 93 93 94 94 <screen role="nodump"><userinput>su - lfs</userinput></screen> … … 96 96 <para>The <quote><parameter>-</parameter></quote> instructs 97 97 <command>su</command> to start a login shell as opposed to a non-login shell. 98 The difference between these two types of shells can be found in detail in98 The difference between these two types of shells is described in detail in 99 99 <filename>bash(1)</filename> and <command>info bash</command>.</para> 100 100 -
chapter04/creatingminlayout.xml
r259794e rdd61c77 11 11 <title>Creating a limited directory layout in LFS filesystem</title> 12 12 13 <para>The next task to be performed in the LFS partition is to create a limited 14 directory hierarchy, so that the programs compiled in <xref 13 <para>In this section, we begin populating the LFS filesystem with the 14 pieces that will constitute the final Linux system. The first step is to 15 create a limited directory hierarchy, so that the programs compiled in <xref 15 16 linkend="chapter-temporary-tools"/> (as well as glibc and libstdc++ in <xref 16 17 linkend="chapter-cross-tools"/>) can be installed in their final -
chapter04/settingenviron.xml
r259794e rdd61c77 20 20 EOF</userinput></screen> 21 21 22 <para>When logged on as user <systemitem class="username">lfs</systemitem>, 23 the initial shell is usually a <emphasis>login</emphasis> shell which reads 22 <para>When logged on as user <systemitem class="username">lfs</systemitem> 23 or switched to the &lfs-user; user using a <command>su</command> command 24 with <quote><parameter>-</parameter></quote> option, 25 the initial shell is a <emphasis>login</emphasis> shell which reads 24 26 the <filename>/etc/profile</filename> of the host (probably containing some 25 27 settings and environment variables) and then <filename>.bash_profile</filename>. … … 33 35 34 36 <para>The new instance of the shell is a <emphasis>non-login</emphasis> 35 shell, which does not read, and execute, the contents of <filename>/etc/profile</filename> or37 shell, which does not read, and execute, the contents of the <filename>/etc/profile</filename> or 36 38 <filename>.bash_profile</filename> files, but rather reads, and executes, the 37 39 <filename>.bashrc</filename> file instead. Create the … … 60 62 <command>bash</command>'s hash function. Hashing is ordinarily a useful 61 63 feature—<command>bash</command> uses a hash table to remember the 62 full path ofexecutable files to avoid searching the <envar>PATH</envar>64 full path to executable files to avoid searching the <envar>PATH</envar> 63 65 time and again to find the same executable. However, the new tools should 64 be used as soon as they are installed. By switching off the hash function,65 the shell will always search the <envar>PATH</envar> whena program is to66 be used as soon as they are installed. Switching off the hash function forces 67 the shell to search the <envar>PATH</envar> whenever a program is to 66 68 be run. As such, the shell will find the newly compiled tools in 67 69 <filename class="directory">$LFS/tools/bin</filename> as soon as they are … … 119 121 <term><parameter>PATH=/usr/bin</parameter></term> 120 122 <listitem> 121 <para>Many modern linux distributions have merged <filename123 <para>Many modern Linux distributions have merged <filename 122 124 class="directory">/bin</filename> and <filename 123 125 class="directory">/usr/bin</filename>. When this is the case, the standard 124 <envar>PATH</envar> variable needs just tobe set to <filename126 <envar>PATH</envar> variable should be set to <filename 125 127 class="directory">/usr/bin/</filename> for the <xref 126 128 linkend="chapter-temporary-tools"/> environment. When this is not the … … 145 147 of <xref linkend="chapter-cross-tools"/> is picked up by the shell 146 148 immediately after its installation. This, combined with turning off hashing, 147 limits the risk that the compiler from the host beused instead of the149 limits the risk that the compiler from the host is used instead of the 148 150 cross-compiler.</para> 149 151 </listitem> … … 199 201 200 202 <para>Finally, to have the environment fully prepared for building the 201 temporary tools, source the just-created user profile:</para> 203 temporary tools, force the <command>bash</command> shell to read 204 the new user profile:</para> 202 205 203 206 <screen><userinput>source ~/.bash_profile</userinput></screen> -
chapter07/creatingdirs.xml
r259794e rdd61c77 11 11 <title>Creating Directories</title> 12 12 13 <para>It is time to create the full structure in the LFS file system.</para>13 <para>It is time to create the full directory structure in the LFS file system.</para> 14 14 15 <note><para>Some of the directories mentioned in this section may be16 already created earlier with explicit instructionsor when installing some15 <note><para>Some of the directories mentioned in this section may have 16 already been created earlier with explicit instructions, or when installing some 17 17 packages. They are repeated below for completeness.</para></note> 18 18 … … 43 43 44 44 <para>Directories are, by default, created with permission mode 755, but 45 this is not desirable for all directories. In the commands above, two45 this is not desirable everywhere. In the commands above, two 46 46 changes are made—one to the home directory of user <systemitem 47 47 class="username">root</systemitem>, and another to the directories for … … 49 49 50 50 <para>The first mode change ensures that not just anybody can enter 51 the <filename class="directory">/root</filename> directory— the52 same as a normal user would do with his or herhome directory. The51 the <filename class="directory">/root</filename> directory—just 52 like a normal user would do with his or her own home directory. The 53 53 second mode change makes sure that any user can write to the 54 54 <filename class="directory">/tmp</filename> and <filename … … 60 60 <title>FHS Compliance Note</title> 61 61 62 <para>Th edirectory tree is based on the Filesystem Hierarchy Standard62 <para>This directory tree is based on the Filesystem Hierarchy Standard 63 63 (FHS) (available at <ulink 64 64 url="https://refspecs.linuxfoundation.org/fhs.shtml"/>). The FHS also specifies 65 the optional existence of somedirectories such as <filename65 the optional existence of additional directories such as <filename 66 66 class="directory">/usr/local/games</filename> and <filename 67 class="directory">/usr/share/games</filename>. We create only the68 directories that are needed. However, feel free to create these69 directories . </para>67 class="directory">/usr/share/games</filename>. In LFS, we create only the 68 directories that are really necessary. However, feel free to create more 69 directories, if you wish. </para> 70 70 71 71 </sect2> -
chapter07/introduction.xml
r259794e rdd61c77 21 21 22 22 <para>This chapter shows how to build the last missing bits of the temporary 23 system: the tools needed by the build machinery ofvarious packages. Now23 system: the tools needed to build the various packages. Now 24 24 that all circular dependencies have been resolved and the temporary system 25 25 is already bootable, we can boot it on the target machine and it would be … … 29 29 <para>For proper operation of the temporary system, some communication 30 30 with the running kernel must be established. This is done through the 31 so-called <emphasis>Virtual Kernel File Systems</emphasis>, which mustbe31 so-called <emphasis>Virtual Kernel File Systems</emphasis>, which will be 32 32 mounted as soon as possible after boot. You may want to check 33 33 that they are mounted by issuing <command>mount</command>.</para> … … 36 36 target system, fortunately without access to the host system. 37 37 Be careful anyway, as if the storage devices of your target system already 38 contain some important data, it's possible to destroy them with bad ly39 formedcommands.</para>38 contain some important data, it's possible to destroy them with bad 39 commands.</para> 40 40 41 41 </sect1> -
chapter07/kernfs.xml
r259794e rdd61c77 15 15 </indexterm> 16 16 17 <para>Various file systems exported by the kernel are used to communicate to 18 and from the kernel itself. These file systems are virtual in that no disk 17 <para>Applications running in user space utilize various file 18 systems exported by the kernel to communicate 19 with the kernel itself. These file systems are virtual: no disk 19 20 space is used for them. The content of the file systems resides in 20 memory.</para> 21 memory. These file systems must be mounted in the $LFS directory tree 22 so the applications can find them in the chroot environment.</para> 21 23 22 <para>Begin by creating directories on towhich the file systems will be24 <para>Begin by creating directories on which the file systems will be 23 25 mounted:</para> 24 26 -
chapter08/autoconf.xml
r259794e rdd61c77 41 41 <sect2 role="installation"> 42 42 <title>Installation of Autoconf</title> 43 <!--44 <para>First, apply a patch fixes several problems that occur with the latest45 perl, libtool, and bash versions.</para>46 43 47 <screen><userinput remap="pre">patch -Np1 -i ../&autoconf-fixes-patch;</userinput></screen> 48 --> 44 <para>First, fix several problems with the tests caused by bash-5.2 and later:</para> 45 46 <screen><userinput remap="pre">sed -e 's/SECONDS|/&SHLVL|/' \ 47 -e '/BASH_ARGV=/a\ /^SHLVL=/ d' \ 48 -i.orig tests/local.at</userinput></screen> 49 49 50 <para>Prepare Autoconf for compilation:</para> 50 51 -
chapter09/udev.xml
r259794e rdd61c77 94 94 </sect3> 95 95 96 <sect3 >96 <sect3 id='ch-config-udev-device-node-creation'> 97 97 <title>Device Node Creation</title> 98 98 -
general.ent
r259794e rdd61c77 122 122 <!ENTITY root "<systemitem class='username'>root</systemitem>"> 123 123 <!ENTITY lfs-user "<systemitem class='username'>lfs</systemitem>"> 124 <!ENTITY devtmpfs "<systemitem class='filesystem'>devtmpfs</systemitem>"> 124 125 <!ENTITY fstab "<filename>/etc/fstab</filename>"> 125 126 <!ENTITY boot-dir "<filename class='directory'>/boot</filename>"> 127 <!ENTITY ch-final "<xref linkend='chapter-building-system'/>"> 128 <!ENTITY ch-tmp-cross "<xref linkend='chapter-temporary-tools'/>"> 129 <!ENTITY ch-tmp-chroot "<xref linkend='chapter-chroot-temporary-tools'/>"> 126 130 127 131 <!ENTITY % packages-entities SYSTEM "packages.ent"> -
packages.ent
r259794e rdd61c77 49 49 <!ENTITY automake-fin-sbu "less than 0.1 SBU (about 7.7 SBU with tests)"> 50 50 51 <!ENTITY bash-version "5. 1.16">52 <!ENTITY bash-size "10, 277KB">51 <!ENTITY bash-version "5.2"> 52 <!ENTITY bash-size "10,695 KB"> 53 53 <!ENTITY bash-url "&gnu;bash/bash-&bash-version;.tar.gz"> 54 <!ENTITY bash-md5 "c 17b20a09fc38d67fb303aeb6c130b4e">54 <!ENTITY bash-md5 "cfb4cf795fc239667f187b3d6b3d396f"> 55 55 <!ENTITY bash-home "&gnu-software;bash/"> 56 56 <!ENTITY bash-tmp-du "64 MB"> … … 59 59 <!ENTITY bash-fin-sbu "1.4 SBU"> 60 60 61 <!ENTITY bc-version "6.0. 2">61 <!ENTITY bc-version "6.0.4"> 62 62 <!ENTITY bc-size "442 KB"> 63 63 <!ENTITY bc-url "https://github.com/gavinhoward/bc/releases/download/&bc-version;/bc-&bc-version;.tar.xz"> 64 <!ENTITY bc-md5 "1 01e62dd9c2b90bf18c38d858aa36f0d">64 <!ENTITY bc-md5 "1e1c90de1a11f3499237425de1673ef1"> 65 65 <!ENTITY bc-home "https://git.yzena.com/gavin/bc"> 66 66 <!ENTITY bc-fin-du "7.4 MB"> … … 115 115 <!ENTITY coreutils-fin-sbu "2.8 SBU"> 116 116 117 <!ENTITY dbus-version "1.14. 0">117 <!ENTITY dbus-version "1.14.2"> 118 118 <!ENTITY dbus-size "1,332 KB"> 119 119 <!ENTITY dbus-url "https://dbus.freedesktop.org/releases/dbus/dbus-&dbus-version;.tar.xz"> 120 <!ENTITY dbus-md5 " ddd5570aff05191dbee8e42d751f1b7d">120 <!ENTITY dbus-md5 "2d9a6b441e6f844d41c35a004f0ef50b"> 121 121 <!ENTITY dbus-home "https://www.freedesktop.org/wiki/Software/dbus"> 122 122 <!ENTITY dbus-fin-du "19 MB"> … … 320 320 <!ENTITY gzip-fin-sbu "0.3 SBU"> 321 321 322 <!ENTITY iana-etc-version "20220 812">322 <!ENTITY iana-etc-version "20220922"> 323 323 <!ENTITY iana-etc-size "584 KB"> 324 324 <!ENTITY iana-etc-url "https://github.com/Mic92/iana-etc/releases/download/&iana-etc-version;/iana-etc-&iana-etc-version;.tar.gz"> 325 <!ENTITY iana-etc-md5 " 851a53efd53c77d0ad7b3d2b68d8a3fc">325 <!ENTITY iana-etc-md5 "2fdc746cfc1bc10f841760fd6a92618c"> 326 326 <!ENTITY iana-etc-home "https://www.iana.org/protocols"> 327 327 <!ENTITY iana-etc-fin-du "4.8 MB"> … … 395 395 <!ENTITY lfs-bootscripts-cfg-sbu "less than 0.1 SBU"> 396 396 397 <!ENTITY libcap-version "2.6 5">398 <!ENTITY libcap-size "17 6KB">397 <!ENTITY libcap-version "2.66"> 398 <!ENTITY libcap-size "178 KB"> 399 399 <!ENTITY libcap-url "&kernel;linux/libs/security/linux-privs/libcap2/libcap-&libcap-version;.tar.xz"> 400 <!ENTITY libcap-md5 " 3543e753dd941255c4def6cc67a462bb">400 <!ENTITY libcap-md5 "00afd6e13bc94b2543b1a70770bdb41f"> 401 401 <!ENTITY libcap-home "https://sites.google.com/site/fullycapable/"> 402 402 <!ENTITY libcap-fin-du "2.7 MB"> 403 403 <!ENTITY libcap-fin-sbu "less than 0.1 SBU"> 404 404 405 <!ENTITY libffi-version "3.4. 2">406 <!ENTITY libffi-size "1,32 0KB">405 <!ENTITY libffi-version "3.4.3"> 406 <!ENTITY libffi-size "1,327 KB"> 407 407 <!ENTITY libffi-url "https://github.com/libffi/libffi/releases/download/v&libffi-version;/libffi-&libffi-version;.tar.gz"> 408 <!ENTITY libffi-md5 " 294b921e6cf9ab0fbaea4b639f8fdbe8">408 <!ENTITY libffi-md5 "b57b0ac1d1072681cee9148a417bd2ec"> 409 409 <!ENTITY libffi-home "https://sourceware.org/libffi/"> 410 410 <!ENTITY libffi-fin-du "10 MB"> … … 429 429 <!ENTITY linux-major-version "5"> 430 430 <!ENTITY linux-minor-version "19"> 431 <!ENTITY linux-patch-version " 8">431 <!ENTITY linux-patch-version "12"> 432 432 <!--<!ENTITY linux-version "&linux-major-version;.&linux-minor-version;">--> 433 433 <!ENTITY linux-version "&linux-major-version;.&linux-minor-version;.&linux-patch-version;"> 434 <!ENTITY linux-size "128,5 47KB">434 <!ENTITY linux-size "128,599 KB"> 435 435 <!ENTITY linux-url "&kernel;linux/kernel/v&linux-major-version;.x/linux-&linux-version;.tar.xz"> 436 <!ENTITY linux-md5 " ae08d14f9b7ed3d47c0d22b6d235507a">436 <!ENTITY linux-md5 "6a8c953d04986027b033bc92185745bf"> 437 437 <!ENTITY linux-home "https://www.kernel.org/"> 438 438 <!-- measured for 5.13.4 / gcc-11.1.0 on x86_64 : minimum is … … 609 609 <!ENTITY python-docs-size "7,176 KB"> 610 610 611 <!ENTITY readline-version "8. 1.2">612 <!ENTITY readline-soversion "8. 1"><!-- used for stripping -->613 <!ENTITY readline-size "2,9 23 KB">611 <!ENTITY readline-version "8.2"> 612 <!ENTITY readline-soversion "8.2"><!-- used for stripping --> 613 <!ENTITY readline-size "2,973 KB"> 614 614 <!ENTITY readline-url "&gnu;readline/readline-&readline-version;.tar.gz"> 615 <!ENTITY readline-md5 " 12819fa739a78a6172400f399ab34f81">615 <!ENTITY readline-md5 "4aa1b31be779e6b84f9a96cb66bc50f6"> 616 616 <!ENTITY readline-home "https://tiswww.case.edu/php/chet/readline/rltop.html"> 617 617 <!ENTITY readline-fin-du "15 MB"> … … 701 701 <!ENTITY texinfo-fin-sbu "0.6 SBU"> 702 702 703 <!ENTITY tzdata-version "2022 c">704 <!ENTITY tzdata-size "42 3KB">703 <!ENTITY tzdata-version "2022d"> 704 <!ENTITY tzdata-size "424 KB"> 705 705 <!ENTITY tzdata-url "https://www.iana.org/time-zones/repository/releases/tzdata&tzdata-version;.tar.gz"> 706 <!ENTITY tzdata-md5 " 4e3b2369b68e713ba5d3f7456f20bfdb">706 <!ENTITY tzdata-md5 "e55dbeb2121230a0ae7c58dbb47ae8c8"> 707 707 <!ENTITY tzdata-home "https://www.iana.org/time-zones"> 708 708 -
part3intro/generalinstructions.xml
r259794e rdd61c77 12 12 <title>General Compilation Instructions</title> 13 13 14 <para>When building packages there are several assumptions made within 15 the instructions:</para> 14 <para>Here are some things you should know about building each package:</para> 16 15 17 16 <itemizedlist> 18 17 19 18 <listitem> 20 <para>Several of thepackages are patched before compilation, but only when19 <para>Several packages are patched before compilation, but only when 21 20 the patch is needed to circumvent a problem. A patch is often needed in 22 both this and the following chapters, but sometimes in only one location. 21 both the current and the following chapters, but sometimes, when the same package 22 is built more than once, the patch is not needed right away. 23 23 Therefore, do not be concerned if instructions for a downloaded patch seem 24 24 to be missing. Warning messages about <emphasis>offset</emphasis> or 25 25 <emphasis>fuzz</emphasis> may also be encountered when applying a patch. Do 26 not worry about these warnings , asthe patch was still successfully26 not worry about these warnings; the patch was still successfully 27 27 applied.</para> 28 28 </listitem> 29 29 30 30 <listitem> 31 <para>During the compilation of most packages, there will be several32 warnings thatscroll by on the screen. These are normal and can safely be33 ignored. These warnings are as they appear—warningsabout31 <para>During the compilation of most packages, some 32 warnings will scroll by on the screen. These are normal and can safely be 33 ignored. These warnings are usually about 34 34 deprecated, but not invalid, use of the C or C++ syntax. C standards change 35 fairly often, and some packages still use the older standard. This is not a36 problem, but does prompt the warning.</para>35 fairly often, and some packages have not yet been updated. This is not a 36 serious problem, but it does cause the warnings to appear.</para> 37 37 </listitem> 38 38 … … 70 70 71 71 <listitem override='bullet'><para><command>/usr/bin/yacc</command> is a 72 symbolic link to <command>bison</command> ora small script that72 symbolic link to <command>bison</command>, or to a small script that 73 73 executes bison.</para></listitem> 74 74 … … 77 77 78 78 <important> 79 <para> To re-emphasize the build process:</para>79 <para>Here is a synopsis of the build process.</para> 80 80 81 81 <orderedlist numeration="arabic" spacing="compact"> 82 82 <listitem> 83 83 <para>Place all the sources and patches in a directory that will be 84 accessible from the chroot environment such as84 accessible from the chroot environment, such as 85 85 <filename class="directory">/mnt/lfs/sources/</filename>.<!-- Do 86 86 <emphasis>not</emphasis> put sources in … … 88 88 </listitem> 89 89 <listitem> 90 <para>Change to the sourcesdirectory.</para>90 <para>Change to the <filename class="directory">/mnt/lfs/sources/</filename> directory.</para> 91 91 </listitem> 92 92 <listitem id='buildinstr' xreflabel='Package build instructions'> … … 98 98 <xref linkend="chapter-temporary-tools"/>, ensure you are 99 99 the <emphasis>lfs</emphasis> user when extracting the package.</para> 100 <para>All methods to get the source code tree being built101 in-position, except extracting the package tarball, are not102 supported. Notably, using <command>cp -R</command>to copy the100 <para>Do not use any method except the <command>tar</command> command 101 to extract the source code. Notably, using the <command>cp -R</command> 102 command to copy the 103 103 source code tree somewhere else can destroy links and 104 timestamps in the sources tree and cause building 105 failure.</para> 104 timestamps in the source tree, and cause the build to fail.</para> 106 105 </listitem> 107 106 <listitem> … … 110 109 </listitem> 111 110 <listitem> 112 <para>Follow the book'sinstructions for building the package.</para>111 <para>Follow the instructions for building the package.</para> 113 112 </listitem> 114 113 <listitem> 115 <para>Change back to the sources directory .</para>114 <para>Change back to the sources directory when the build is complete.</para> 116 115 </listitem> 117 116 <listitem> -
part3intro/introduction.xml
r259794e rdd61c77 11 11 <title>Introduction</title> 12 12 13 <para>This part is divided into three stages: first building a cross14 compiler and its associated libraries; second, us ethis cross toolchain13 <para>This part is divided into three stages: first, building a cross 14 compiler and its associated libraries; second, using this cross toolchain 15 15 to build several utilities in a way that isolates them from the host 16 distribution; third, enter the chroot environment,which further improves17 host isolation , and buildthe remaining tools needed to build the final16 distribution; and third, entering the chroot environment (which further improves 17 host isolation) and constructing the remaining tools needed to build the final 18 18 system.</para> 19 19 20 <important><para> With this part begins the real work of building a new21 system. It requires much care in ensuring that the instructions are22 followed exactly as the book shows them. You should try to understand23 what they do, and whatever your eagernessto finish your build, you should24 refrain from blindly typ e them as shown, but rather readdocumentation when20 <important><para>This is where the real work of building a new system 21 begins. Be very careful to follow the instructions exactly as the book 22 shows them. You should try to understand what each command does, 23 and no matter how eager you are to finish your build, you should 24 refrain from blindly typing the commands as shown. Read the documentation when 25 25 there is something you do not understand. Also, keep track of your typing 26 and of the output of commands, by sending them to a file, using the27 <command>tee</command> utility. This allows for better diagnosing28 if something g ets wrong.</para></important>26 and of the output of commands, by using the <command>tee</command> utility 27 to send the terminal output to a file. This makes debugging easier 28 if something goes wrong.</para></important> 29 29 30 <para>The next section gives a technical introduction to the build process,31 while the following one contains <emphasis role="strong">very30 <para>The next section is a technical introduction to the build process, 31 while the following one presents <emphasis role="strong">very 32 32 important</emphasis> general instructions.</para> 33 33 -
part3intro/toolchaintechnotes.xml
r259794e rdd61c77 12 12 13 13 <para>This section explains some of the rationale and technical details 14 behind the overall build method. It is not essentialto immediately14 behind the overall build method. Don't try to immediately 15 15 understand everything in this section. Most of this information will be 16 clearer after performing an actual build. This section can be referred17 to at any time during theprocess.</para>16 clearer after performing an actual build. Come back and re-read this chapter 17 at any time during the build process.</para> 18 18 19 19 <para>The overall goal of <xref linkend="chapter-cross-tools"/> and <xref 20 linkend="chapter-temporary-tools"/> is to produce a temporary area that21 contain s a known-good set of tools that can be isolated from the host system.22 By using <command>chroot</command>, the commands in the remaining chapters23 will be contained within that environment, ensuring a clean, trouble-free20 linkend="chapter-temporary-tools"/> is to produce a temporary area 21 containing a set of tools that are known to be good, and that are isolated from the host system. 22 By using the <command>chroot</command> command, the compilations in the remaining chapters 23 will be isolated within that environment, ensuring a clean, trouble-free 24 24 build of the target LFS system. The build process has been designed to 25 minimize the risks for new readers and to provide the most educational value25 minimize the risks for new readers, and to provide the most educational value 26 26 at the same time.</para> 27 27 28 <para>Th e build process is based on the process of28 <para>This build process is based on 29 29 <emphasis>cross-compilation</emphasis>. Cross-compilation is normally used 30 for building a compiler and itstoolchain for a machine different from31 the one that is used for the build. This is not strictly ne ededfor LFS,30 to build a compiler and its associated toolchain for a machine different from 31 the one that is used for the build. This is not strictly necessary for LFS, 32 32 since the machine where the new system will run is the same as the one 33 used for the build. But cross-compilation has the great advantage that33 used for the build. But cross-compilation has one great advantage: 34 34 anything that is cross-compiled cannot depend on the host environment.</para> 35 35 … … 40 40 <note> 41 41 <para> 42 The LFS book is not , and does not containa general tutorial to43 build a cross (or native) toolchain. Don't use the command in the44 book for a cross toolchain which will be usedfor some purpose other42 The LFS book is not (and does not contain) a general tutorial to 43 build a cross (or native) toolchain. Don't use the commands in the 44 book for a cross toolchain for some purpose other 45 45 than building LFS, unless you really understand what you are doing. 46 46 </para> 47 47 </note> 48 48 49 <para>Cross-compilation involves some concepts that deserve a section o n50 their own. Although this section may be omitted in a first reading,51 coming back to it later will be beneficial to your fullunderstanding of49 <para>Cross-compilation involves some concepts that deserve a section of 50 their own. Although this section may be omitted on a first reading, 51 coming back to it later will help you gain a fuller understanding of 52 52 the process.</para> 53 53 54 <para>Let us first define some terms used in this context :</para>54 <para>Let us first define some terms used in this context.</para> 55 55 56 56 <variablelist> 57 <varlistentry><term> build</term><listitem>57 <varlistentry><term>The build</term><listitem> 58 58 <para>is the machine where we build programs. Note that this machine 59 is referred to as the <quote>host</quote> in other 60 sections.</para></listitem> 59 is also referred to as the <quote>host</quote>.</para></listitem> 61 60 </varlistentry> 62 61 63 <varlistentry><term> host</term><listitem>62 <varlistentry><term>The host</term><listitem> 64 63 <para>is the machine/system where the built programs will run. Note 65 64 that this use of <quote>host</quote> is not the same as in other … … 67 66 </varlistentry> 68 67 69 <varlistentry><term> target</term><listitem>68 <varlistentry><term>The target</term><listitem> 70 69 <para>is only used for compilers. It is the machine the compiler 71 produces code for. It may be different from both build and72 host.</para></listitem>70 produces code for. It may be different from both the build and 71 the host.</para></listitem> 73 72 </varlistentry> 74 73 … … 76 75 77 76 <para>As an example, let us imagine the following scenario (sometimes 78 referred to as <quote>Canadian Cross</quote>): we mayhave a77 referred to as <quote>Canadian Cross</quote>): we have a 79 78 compiler on a slow machine only, let's call it machine A, and the compiler 80 ccA. We may have also a fast machine (B), but with no compiler, and we may81 want to produce code for a nother slow machine (C). Tobuild a82 compiler for machine C , we would have three stages:</para>79 ccA. We also have a fast machine (B), but no compiler for (B), and we 80 want to produce code for a third, slow machine (C). We will build a 81 compiler for machine C in three stages.</para> 83 82 84 83 <informaltable align="center"> … … 96 95 <row> 97 96 <entry>1</entry><entry>A</entry><entry>A</entry><entry>B</entry> 98 <entry> build cross-compiler cc1 using ccA on machine A</entry>97 <entry>Build cross-compiler cc1 using ccA on machine A.</entry> 99 98 </row> 100 99 <row> 101 100 <entry>2</entry><entry>A</entry><entry>B</entry><entry>C</entry> 102 <entry> build cross-compiler cc2 using cc1 on machine A</entry>101 <entry>Build cross-compiler cc2 using cc1 on machine A.</entry> 103 102 </row> 104 103 <row> 105 104 <entry>3</entry><entry>B</entry><entry>C</entry><entry>C</entry> 106 <entry> build compiler ccC using cc2 on machine B</entry>105 <entry>Build compiler ccC using cc2 on machine B.</entry> 107 106 </row> 108 107 </tbody> … … 110 109 </informaltable> 111 110 112 <para>Then, all the otherprograms needed by machine C can be compiled111 <para>Then, all the programs needed by machine C can be compiled 113 112 using cc2 on the fast machine B. Note that unless B can run programs 114 produced for C, there is no way to test the built programs until machine115 C itself is running. For example, for testingccC, we may want to add a113 produced for C, there is no way to test the newly built programs until machine 114 C itself is running. For example, to run a test suite on ccC, we may want to add a 116 115 fourth stage:</para> 117 116 … … 130 129 <row> 131 130 <entry>4</entry><entry>C</entry><entry>C</entry><entry>C</entry> 132 <entry> rebuild and test ccC using itself on machine C</entry>131 <entry>Rebuild and test ccC using ccC on machine C.</entry> 133 132 </row> 134 133 </tbody> … … 147 146 148 147 <note> 149 <para>Almost all the build systems use names of the form 150 cpu-vendor-kernel-os referred to as the machine triplet. An astute 151 reader may wonder why a <quote>triplet</quote> refers to a four component 152 name. The reason is history: initially, three component names were enough 153 to designate a machine unambiguously, but with new machines and systems 154 appearing, that proved insufficient. The word <quote>triplet</quote> 155 remained. A simple way to determine your machine triplet is to run 156 the <command>config.guess</command> 148 <para>All packages involved with cross compilation in the book use an 149 autoconf-based building system. The autoconf-based building system 150 accepts system types in the form cpu-vendor-kernel-os, 151 referred to as the system triplet. Since the vendor field is mostly 152 irrelevant, autoconf allows to omit it. An astute reader may wonder 153 why a <quote>triplet</quote> refers to a four component name. The 154 reason is the kernel field and the os field originiated from one 155 <quote>system</quote> field. Such a three-field form is still valid 156 today for some systems, for example 157 <literal>x86_64-unknown-freebsd</literal>. But for other systems, 158 two systems can share the same kernel but still be too different to 159 use a same triplet for them. For example, an Android running on a 160 mobile phone is completely different from Ubuntu running on an ARM64 161 server, despite they are running on the same type of CPU (ARM64) and 162 using the same kernel (Linux). 163 Without an emulation layer, you cannot run an 164 executable for the server on the mobile phone or vice versa. So the 165 <quote>system</quote> field is separated into kernel and os fields to 166 designate these systems unambiguously. For our example, the Android 167 system is designated <literal>aarch64-unknown-linux-android</literal>, 168 and the Ubuntu system is designated 169 <literal>aarch64-unknown-linux-gnu</literal>. The word 170 <quote>triplet</quote> remained. A simple way to determine your 171 system triplet is to run the <command>config.guess</command> 157 172 script that comes with the source for many packages. Unpack the binutils 158 173 sources and run the script: <userinput>./config.guess</userinput> and note 159 174 the output. For example, for a 32-bit Intel processor the 160 175 output will be <emphasis>i686-pc-linux-gnu</emphasis>. On a 64-bit 161 system it will be <emphasis>x86_64-pc-linux-gnu</emphasis>.</para> 162 163 <para>Also be aware of the name of the platform's dynamic linker, often 176 system it will be <emphasis>x86_64-pc-linux-gnu</emphasis>. On most 177 Linux systems the even simpler <command>gcc -dumpmachine</command> command 178 will give you similar information.</para> 179 180 <para>You should also be aware of the name of the platform's dynamic linker, often 164 181 referred to as the dynamic loader (not to be confused with the standard 165 182 linker <command>ld</command> that is part of binutils). The dynamic linker 166 provided by Glibc finds and loads the shared libraries needed by a183 provided by package glibc finds and loads the shared libraries needed by a 167 184 program, prepares the program to run, and then runs it. The name of the 168 185 dynamic linker for a 32-bit Intel machine is <filename 169 class="libraryfile">ld-linux.so.2</filename> and is <filename170 class="libraryfile">ld-linux-x86-64.so.2</filename> for64-bit systems. A186 class="libraryfile">ld-linux.so.2</filename>; it's <filename 187 class="libraryfile">ld-linux-x86-64.so.2</filename> on 64-bit systems. A 171 188 sure-fire way to determine the name of the dynamic linker is to inspect a 172 189 random binary from the host system by running: <userinput>readelf -l 173 190 <name of binary> | grep interpreter</userinput> and noting the 174 191 output. The authoritative reference covering all platforms is in the 175 <filename>shlib-versions</filename> file in the root of the Glibc source192 <filename>shlib-versions</filename> file in the root of the glibc source 176 193 tree.</para> 177 194 </note> … … 179 196 <para>In order to fake a cross compilation in LFS, the name of the host triplet 180 197 is slightly adjusted by changing the "vendor" field in the 181 <envar>LFS_TGT</envar> variable . We also use the198 <envar>LFS_TGT</envar> variable so it says "lfs". We also use the 182 199 <parameter>--with-sysroot</parameter> option when building the cross linker and 183 200 cross compiler to tell them where to find the needed host files. This 184 201 ensures that none of the other programs built in <xref 185 202 linkend="chapter-temporary-tools"/> can link to libraries on the build 186 machine. Only two stages are mandatory, and one more for tests:</para>203 machine. Only two stages are mandatory, plus one more for tests.</para> 187 204 188 205 <informaltable align="center"> … … 200 217 <row> 201 218 <entry>1</entry><entry>pc</entry><entry>pc</entry><entry>lfs</entry> 202 <entry> build cross-compiler cc1 using cc-pc on pc</entry>219 <entry>Build cross-compiler cc1 using cc-pc on pc.</entry> 203 220 </row> 204 221 <row> 205 222 <entry>2</entry><entry>pc</entry><entry>lfs</entry><entry>lfs</entry> 206 <entry> build compiler cc-lfs using cc1 on pc</entry>223 <entry>Build compiler cc-lfs using cc1 on pc.</entry> 207 224 </row> 208 225 <row> 209 226 <entry>3</entry><entry>lfs</entry><entry>lfs</entry><entry>lfs</entry> 210 <entry> rebuild and test cc-lfs using itself on lfs</entry>227 <entry>Rebuild and test cc-lfs using cc-lfs on lfs.</entry> 211 228 </row> 212 229 </tbody> … … 214 231 </informaltable> 215 232 216 <para>In the abovetable, <quote>on pc</quote> means the commands are run233 <para>In the preceding table, <quote>on pc</quote> means the commands are run 217 234 on a machine using the already installed distribution. <quote>On 218 235 lfs</quote> means the commands are run in a chrooted environment.</para> … … 220 237 <para>Now, there is more about cross-compiling: the C language is not 221 238 just a compiler, but also defines a standard library. In this book, the 222 GNU C library, named glibc, is used . This library must223 be compiled for the lfs machine,that is, using the cross compiler cc1.239 GNU C library, named glibc, is used (there is an alternative, "musl"). This library must 240 be compiled for the LFS machine; that is, using the cross compiler cc1. 224 241 But the compiler itself uses an internal library implementing complex 225 instructions not available in the assembler instruction set. This226 internal library is named libgcc, and must be linked to the glibc242 subroutines for functions not available in the assembler instruction set. This 243 internal library is named libgcc, and it must be linked to the glibc 227 244 library to be fully functional! Furthermore, the standard library for 228 C++ (libstdc++) also needs being linked toglibc. The solution to this229 chicken and egg problem is to first build a degraded cc1based libgcc,230 lacking some functionalities such as threads and exception handling, then231 build glibc using this degraded compiler (glibc itself is not232 degraded), then build libstdc++. But this last library will lackthe233 same functionalities aslibgcc.</para>234 235 <para>This is not the end of the story: the conclusionof the preceding245 C++ (libstdc++) must also be linked with glibc. The solution to this 246 chicken and egg problem is first to build a degraded cc1-based libgcc, 247 lacking some functionalities such as threads and exception handling, and then 248 to build glibc using this degraded compiler (glibc itself is not 249 degraded), and also to build libstdc++. This last library will lack some of the 250 functionality of libgcc.</para> 251 252 <para>This is not the end of the story: the upshot of the preceding 236 253 paragraph is that cc1 is unable to build a fully functional libstdc++, but 237 254 this is the only compiler available for building the C/C++ libraries 238 255 during stage 2! Of course, the compiler built during stage 2, cc-lfs, 239 256 would be able to build those libraries, but (1) the build system of 240 GCC does not know that it is usable on pc, and (2) using it on pc 241 would be at risk of linking to the pc libraries, since cc-lfs is a native 242 compiler. So we have to build libstdc++ later, in chroot.</para> 257 gcc does not know that it is usable on pc, and (2) using it on pc 258 would create a risk of linking to the pc libraries, since cc-lfs is a native 259 compiler. So we have to re-build libstdc++ later as a part of 260 gcc stage 2.</para> 261 262 <para>In &ch-final; (or <quote>stage 3</quote>), all packages needed for 263 the LFS system are built. Even if a package is already installed into 264 the LFS system in a previous chapter, we still rebuild the package 265 unless we are completely sure it's unnecessary. The main reason for 266 rebuilding these packages is to settle them down: if we reinstall a LFS 267 package on a complete LFS system, the installed content of the package 268 should be same as the content of the same package installed in 269 &ch-final;. The temporary packages installed in &ch-tmp-cross; or 270 &ch-tmp-chroot; cannot satisify this expectation because some of them 271 are built without optional dependencies installed, and autoconf cannot 272 perform some feature checks in &ch-tmp-cross; because of cross 273 compilation, causing the temporary packages to lack optional features 274 or use suboptimal code routines. Additionally, a minor reason for 275 rebuilding the packages is allowing to run the testsuite.</para> 243 276 244 277 </sect2> … … 253 286 254 287 <para>Binutils is installed first because the <command>configure</command> 255 runs of both GCC and Glibc perform various feature tests on the assembler288 runs of both gcc and glibc perform various feature tests on the assembler 256 289 and linker to determine which software features to enable or disable. This 257 is more important than one might first realize. An incorrectly configured258 GCC or Glibc can result in a subtly broken toolchain, where the impact of290 is more important than one might realize at first. An incorrectly configured 291 gcc or glibc can result in a subtly broken toolchain, where the impact of 259 292 such breakage might not show up until near the end of the build of an 260 293 entire distribution. A test suite failure will usually highlight this error … … 275 308 will show all the files successfully opened during the linking.</para> 276 309 277 <para>The next package installed is GCC. An example of what can be310 <para>The next package installed is gcc. An example of what can be 278 311 seen during its run of <command>configure</command> is:</para> 279 312 … … 282 315 283 316 <para>This is important for the reasons mentioned above. It also 284 demonstrates that GCC's configure script does not search the PATH317 demonstrates that gcc's configure script does not search the PATH 285 318 directories to find which tools to use. However, during the actual 286 319 operation of <command>gcc</command> itself, the same search paths are not … … 296 329 297 330 <para>Next installed are sanitized Linux API headers. These allow the 298 standard C library ( Glibc) to interface with features that the Linux331 standard C library (glibc) to interface with features that the Linux 299 332 kernel will provide.</para> 300 333 301 <para>The next package installed is Glibc. The most important302 considerations for building Glibc are the compiler, binary tools, and303 kernel headers. The compiler is generally not an issue since Glibc will334 <para>The next package installed is glibc. The most important 335 considerations for building glibc are the compiler, binary tools, and 336 kernel headers. The compiler is generally not an issue since glibc will 304 337 always use the compiler relating to the <parameter>--host</parameter> 305 338 parameter passed to its configure script; e.g. in our case, the compiler … … 314 347 and the use of the <parameter>-nostdinc</parameter> and 315 348 <parameter>-isystem</parameter> flags to control the compiler's include 316 search path. These items highlight an important aspect of the Glibc349 search path. These items highlight an important aspect of the glibc 317 350 package—it is very self-sufficient in terms of its build machinery 318 351 and generally does not rely on toolchain defaults.</para> 319 352 320 <para>As said above, the standard C++ library is compiled next, followed in 321 <xref linkend="chapter-temporary-tools"/> by all the programs that need 322 themselves to be built. The install step of all those packages uses the 323 <envar>DESTDIR</envar> variable to have the 324 programs land into the LFS filesystem.</para> 353 <para>As mentioned above, the standard C++ library is compiled next, followed in 354 <xref linkend="chapter-temporary-tools"/> by other programs that need 355 to be cross compiled for breaking circular dependencies at build time. 356 The install step of all those packages uses the 357 <envar>DESTDIR</envar> variable to force installation 358 in the LFS filesystem.</para> 325 359 326 360 <para>At the end of <xref linkend="chapter-temporary-tools"/> the native 327 lfscompiler is installed. First binutils-pass2 is built,328 with the same <envar>DESTDIR</envar> installas the other programs,329 then the second pass of GCC is constructed, omitting libstdc++330 and other non-important libraries. Due to some weird logic in GCC's361 LFS compiler is installed. First binutils-pass2 is built, 362 in the same <envar>DESTDIR</envar> directory as the other programs, 363 then the second pass of gcc is constructed, omitting some 364 non-critical libraries. Due to some weird logic in gcc's 331 365 configure script, <envar>CC_FOR_TARGET</envar> ends up as 332 <command>cc</command> when the host is the same as the target, but is366 <command>cc</command> when the host is the same as the target, but 333 367 different from the build system. This is why 334 <parameter>CC_FOR_TARGET=$LFS_TGT-gcc</parameter> is put explicitly into335 the configureoptions.</para>368 <parameter>CC_FOR_TARGET=$LFS_TGT-gcc</parameter> is declared explicitly 369 as one of the configuration options.</para> 336 370 337 371 <para>Upon entering the chroot environment in <xref 338 linkend="chapter-chroot-temporary-tools"/>, the first task is to install339 libstdc++. Thentemporary installations of programs needed for the proper372 linkend="chapter-chroot-temporary-tools"/>, 373 the temporary installations of programs needed for the proper 340 374 operation of the toolchain are performed. From this point onwards, the 341 375 core toolchain is self-contained and self-hosted. In
Note:
See TracChangeset
for help on using the changeset viewer.