Changeset 675606b for chapter05/glibc.xml
- Timestamp:
- 06/16/2020 11:56:28 AM (4 years ago)
- Branches:
- 10.0, 10.0-rc1, 10.1, 10.1-rc1, 11.0, 11.0-rc1, 11.0-rc2, 11.0-rc3, 11.1, 11.1-rc1, 11.2, 11.2-rc1, 11.3, 11.3-rc1, 12.0, 12.0-rc1, 12.1, 12.1-rc1, arm, bdubbs/gcc13, ml-11.0, multilib, renodr/libudev-from-systemd, s6-init, trunk, xry111/arm64, xry111/arm64-12.0, xry111/clfs-ng, xry111/lfs-next, xry111/loongarch, xry111/loongarch-12.0, xry111/loongarch-12.1, xry111/mips64el, xry111/pip3, xry111/rust-wip-20221008, xry111/update-glibc
- Children:
- 9a05e45
- Parents:
- 560065f (diff), 1cd5961 (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. - File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter05/glibc.xml
r560065f r675606b 26 26 27 27 <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" 28 href="../chapter0 6/glibc.xml"28 href="../chapter08/glibc.xml" 29 29 xpointer="xpointer(/sect1/sect2[1]/para[1])"/> 30 30 … … 34 34 35 35 <seglistitem> 36 <seg>&glibc- ch5-sbu;</seg>37 <seg>&glibc- ch5-du;</seg>36 <seg>&glibc-tmp-sbu;</seg> 37 <seg>&glibc-tmp-du;</seg> 38 38 </seglistitem> 39 39 </segmentedlist> … … 44 44 <title>Installation of Glibc</title> 45 45 46 <para>First, create a symbolic link for LSB compliance. Additionally, 47 for x86_64, create a compatibility symbolic link required for proper 48 operation of the dynamic library loader:</para> 49 50 <screen><userinput remap="pre">case $(uname -m) in 51 i?86) ln -sfv ld-linux.so.2 $LFS/lib/ld-lsb.so.3 52 ;; 53 x86_64) ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64 54 ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64/ld-lsb-x86-64.so.3 55 ;; 56 esac</userinput></screen> 57 58 <para>Some of the Glibc programs use the non-FHS compliant 59 <filename class="directory">/var/db</filename> directory to store their 60 runtime data. Apply the following patch to make such programs store their 61 runtime data in the FHS-compliant locations:</para> 62 63 <screen><userinput remap="pre">patch -Np1 -i ../glibc-&glibc-version;-fhs-1.patch</userinput></screen> 64 46 65 <para>The Glibc documentation recommends building Glibc 47 66 in a dedicated build directory:</para> … … 53 72 54 73 <screen><userinput remap="configure">../configure \ 55 --prefix=/ tools\74 --prefix=/usr \ 56 75 --host=$LFS_TGT \ 57 76 --build=$(../scripts/config.guess) \ 58 77 --enable-kernel=&min-kernel; \ 59 --with-headers=/tools/include</userinput></screen> 78 --with-headers=$LFS/usr/include \ 79 libc_cv_slibdir=/lib</userinput></screen> 60 80 <!-- 61 81 libc_cv_forced_unwind=yes \ … … 69 89 <listitem> 70 90 <para>The combined effect of these switches is that Glibc's build system 71 configures itself to cross-compile, using the cross-linker and91 configures itself to be cross-compiled, using the cross-linker and 72 92 cross-compiler in <filename class="directory">/tools</filename>.</para> 73 93 </listitem> … … 84 104 85 105 <varlistentry> 86 <term><parameter>--with-headers=/tools/include</parameter></term> 87 <listitem> 88 <para>This tells Glibc to compile itself against the headers recently 89 installed to the tools directory, so that it knows exactly what 90 features the kernel has and can optimize itself accordingly.</para> 91 </listitem> 92 </varlistentry> 93 <!-- 94 <varlistentry> 95 <term><parameter>libc_cv_forced_unwind=yes</parameter></term> 96 <listitem> 97 <para>The linker installed during 98 <xref linkend="ch-tools-binutils-pass1"/> was cross-compiled and as 99 such cannot be used until Glibc has been installed. This means that 100 the configure test for force-unwind support will fail, as it relies on 101 a working linker. The libc_cv_forced_unwind=yes variable is passed in 102 order to inform <command>configure</command> that force-unwind 103 support is available without it having to run the test.</para> 104 </listitem> 105 </varlistentry> 106 <varlistentry> 107 <term><parameter>libc_cv_c_cleanup=yes</parameter></term> 108 <listitem> 109 <para>Similarly, we pass libc_cv_c_cleanup=yes through to the 110 <command>configure</command> script so that the test is skipped and C 111 cleanup handling support is configured.</para> 112 </listitem> 113 </varlistentry> 114 --> 115 <!-- <varlistentry> 116 <term><parameter>libc_cv_ctors_header=yes</parameter></term> 117 <listitem> 118 <para>Similarly, we pass libc_cv_ctors_header=yes through to the 119 <command>configure</command> script so that the test is skipped and 120 gcc constructor support is configured.</para> 121 </listitem> 122 </varlistentry>--> 106 <term><parameter>--with-headers=$LFS/usr/include</parameter></term> 107 <listitem> 108 <para>This tells Glibc to compile itself against the headers 109 recently installed to the $LFS/usr/include directory, so that 110 it knows exactly what features the kernel has and can optimize 111 itself accordingly.</para> 112 </listitem> 113 </varlistentry> 114 115 <varlistentry> 116 <term><parameter>libc_cv_slibdir=/lib</parameter></term> 117 <listitem> 118 <para>This ensures that the library is installed in /lib instead 119 of the default /lib64 on 64 bit machines.</para> 120 </listitem> 121 </varlistentry> 123 122 124 123 </variablelist> … … 148 147 <para>Install the package:</para> 149 148 150 <screen><userinput remap="install">make install</userinput></screen> 151 152 <caution> 153 <para>At this point, it is imperative to stop and ensure that the basic 154 functions (compiling and linking) of the new toolchain are working as 155 expected. To perform a sanity check, run the following commands:</para> 149 <warning><para>If <envar>LFS</envar> is not properly set, and despite the 150 recommendations, you are building as root, the next command will install 151 the newly built glibc to your host system, which most likely will render it 152 unusable. So double check that the environment is correctly set for user 153 <systemitem class="username">lfs</systemitem>.</para></warning> 154 155 <screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen> 156 157 <variablelist> 158 <title>The meaning of the <command>make install</command> option:</title> 159 160 <varlistentry> 161 <term><parameter>DESTDIR=$LFS</parameter></term> 162 <listitem> 163 <para>The <envar>DESTDIR</envar> make variable is used by almost all 164 packages to define the location where the package should be 165 installed. If it is not set, it defaults to the root (<filename 166 class="directory">/</filename>) directory. Here we specify that 167 the package be installed in <filename class="directory">$LFS 168 </filename>, which will become the root after <xref linkend= 169 "ch-tools-chroot"/>.</para> 170 </listitem> 171 </varlistentry> 172 173 </variablelist> 174 175 <caution> 176 <para>At this point, it is imperative to stop and ensure that the basic 177 functions (compiling and linking) of the new toolchain are working as 178 expected. To perform a sanity check, run the following commands:</para> 156 179 157 180 <screen><userinput>echo 'int main(){}' > dummy.c 158 181 $LFS_TGT-gcc dummy.c 159 readelf -l a.out | grep ' : /tools'</userinput></screen>160 161 <para>If everything is working correctly, there should be no errors,162 and the output of the last command will be of the form:</para>163 164 <screen><computeroutput>[Requesting program interpreter: / tools/lib64/ld-linux-x86-64.so.2]</computeroutput></screen>165 166 <para>Note that for 32-bit machines, the interpreter name will be167 <filename>/tools/lib/ld-linux.so.2</filename>.</para>168 169 <para>If the output is not shown as above or there was no output at all,170 then something is wrong. Investigate and retrace the steps to find out171 where the problem is and correct it. This issue must be resolved before172 continuing on.</para>173 174 <para>Once all is well, clean up the test files:</para>182 readelf -l a.out | grep '/ld-linux'</userinput></screen> 183 184 <para>If everything is working correctly, there should be no errors, 185 and the output of the last command will be of the form:</para> 186 187 <screen><computeroutput>[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]</computeroutput></screen> 188 189 <para>Note that for 32-bit machines, the interpreter name will be 190 <filename>/lib/ld-linux.so.2</filename>.</para> 191 192 <para>If the output is not shown as above or there was no output at all, 193 then something is wrong. Investigate and retrace the steps to find out 194 where the problem is and correct it. This issue must be resolved before 195 continuing on.</para> 196 197 <para>Once all is well, clean up the test files:</para> 175 198 176 199 <screen><userinput>rm -v dummy.c a.out</userinput></screen> 177 200 178 </caution> 179 180 <note><para>Building Binutils in the section after next will serve as an 181 additional check that the toolchain has been built properly. If Binutils 182 fails to build, it is an indication that something has gone wrong with the 183 previous Binutils, GCC, or Glibc installations.</para></note> 201 </caution> 202 203 <note><para>Building packages in the next chapter will serve as an 204 additional check that the toolchain has been built properly. If some 205 package, especially binutils-pass2 or gcc-pass2, fails to build, it is 206 an indication that something has gone wrong with the 207 previous Binutils, GCC, or Glibc installations.</para></note> 208 209 <para>Now that our cross-toolchain is complete, finalize the installation 210 of the limits.h header. For doing so, run a utility provided by the GCC 211 developers:</para> 212 213 <screen><userinput>$LFS/tools/libexec/gcc/$LFS_TGT/&gcc-version;/install-tools/mkheaders</userinput></screen> 184 214 185 215 </sect2>
Note:
See TracChangeset
for help on using the changeset viewer.