Changeset f57e3d1
- Timestamp:
- 10/07/2003 12:41:12 AM (21 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, 6.0, 6.1, 6.1.1, 6.3, 6.4, 6.5, 6.6, 6.7, 6.8, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.5-systemd, 7.6, 7.6-systemd, 7.7, 7.7-systemd, 7.8, 7.8-systemd, 7.9, 7.9-systemd, 8.0, 8.1, 8.2, 8.3, 8.4, 9.0, 9.1, arm, bdubbs/gcc13, ml-11.0, multilib, renodr/libudev-from-systemd, s6-init, trunk, v5_0, v5_1, v5_1_1, 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:
- f861982
- Parents:
- 04a3351
- Files:
-
- 8 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter01/changelog.xml
r04a3351 rf57e3d1 96 96 </para></listitem> 97 97 98 <listitem><para>October 6th, 2003 [greg]: Simplify seds in "Locking in Glibc" 99 and "Re-adjusting the toolchain" sections. Rearrange "How things are going to be 100 done" section.</para></listitem> 101 98 102 <listitem><para>October 5th, 2003 [greg]: Chapter 5: Add new section "Toolchain 99 103 technical notes". Integrate and scale back the old "Why we use static linking" -
chapter01/how.xml
r04a3351 rf57e3d1 10 10 as one of the options when you installed your distribution.</para> 11 11 12 <para>In Chapter 3 you will first create a new Linux native partition and 13 filesystem, the place where your new LFS system will be compiled and installed. 14 Then in Chapter 4 you download all the packages and patches required to build 15 an LFS system, and store them on the new filesystem.</para>12 <para>In Chapter 3 you will first create a new Linux native partition and file 13 system, the place where your new LFS system will be compiled and installed. Then 14 in Chapter 4 you download all the packages and patches required to build an LFS 15 system, and store them on the new file system.</para> 16 16 17 <para>Chapter 5 will then discuss the installation of a number of packages that 18 will form the basic development suite (or tool -set) which is used to build the19 actual system in Chapter 6. Some of these packages are needed to resolve 20 circular dependencies. For example, to compile a compiler you need a 17 <para>Chapter 5 will then discuss the installation of a number of packages that 18 will form the basic development suite (or toolchain) which is used to build the 19 actual system in Chapter 6. Some of these packages are needed to resolve 20 circular dependencies. For example, to compile a compiler you need a 21 21 compiler.</para> 22 22 … … 26 26 of the host system. The second thing to do is build Glibc, the C library. Glibc 27 27 will be compiled by the toolchain programs we just built in the first 28 pass.</para> 28 pass. The third thing to do is build a second pass of the toolchain. This time 29 the toolchain will be dynamically linked against the newly built Glibc. The 30 remaining Chapter 5 packages are all built using this second pass toolchain and 31 dynamically linked against the new host-independent Glibc. When this is done, 32 the LFS installation process will no longer depend on the host distribution, 33 with the exception of the running kernel.</para> 29 34 30 <para>The third thing to do is build a second pass of the toolchain. This time 31 the toolchain will be dynamically linked against the newly built Glibc. The 32 remaining Chapter 5 packages are all built using this second pass toolchain and 33 dynamically linked against the new host-independent Glibc. When this is done, 34 the LFS installation process will no longer depend on the host distribution, 35 with the exception of the running kernel. This is known as <quote>self 36 contained</quote> and <quote>self hosted</quote>. There is a discussion of the 37 differences between statically and dynamically linked programs at the beginning 38 of Chapter 5.</para> 39 40 <para>You may be asking yourself <quote>that seems like a lot of work, just to 41 get away from my host distribution</quote>. Let us take a few minutes to 42 discuss this question. The work involved in building the packages in Chapter 5 43 is to ensure that as little information as possible from your host makes it into 44 your brand new LFS system. When you build the first two packages in Chapter 5, 45 Binutils and GCC, they will be compiled statically. This means that the 46 version of the C library on your host distribution will be embedded inside all 47 the binary programs you just compiled. This has the potential to cause 48 problems for you down the road. The host's Glibc is usually an unknown 49 quantity and might even contain bugs or anything else we don't know about 50 until it is too late. A well known issue is that statically linked binaries 51 compiled on a Glibc-2.2.x based system that contain calls to the 52 <emphasis>getpwuid()</emphasis> function crash when run on a Glibc-2.3.x based 53 system. Seeing as we are about to build a Glibc-2.3.x based system, we need to 54 shield ourselves from problems of this nature. The procedure employed in 55 Chapter 5 achieves this goal. With all these things in mind, you can see that 56 the extra effort to compile Binutils and GCC twice is well worth it.</para> 35 <para>You may be asking yourself <quote>that seems like a lot of work, just to 36 get away from my host distribution?</quote>. A full technical and in-depth 37 explanation is provided at the start of Chapter 5, including some notes on the 38 differences between statically and dynamically linked programs.</para> 57 39 58 40 <para>In Chapter 6 your real LFS system will be built. The chroot (change root) -
chapter05/gcc-pass2-inst.xml
r04a3351 rf57e3d1 156 156 we performed earlier in the chapter. Refer back to the "Locking in" Glibc section 157 157 and repeat the check. If the results are wrong then most likely, you forgot to 158 apply the above mentioned GCC Specs patch.</para></note>158 apply the above mentioned GCC Specs patch.</para></note> 159 159 160 160 </sect2> -
chapter05/lockingglibc.xml
r04a3351 rf57e3d1 24 24 25 25 <para><screen><userinput>SPECFILE=/tools/lib/gcc-lib/*/*/specs 26 sed -e 's@/lib/ld.so.1@/tools/lib/ld.so.1@g' \ 27 -e 's@/lib/ld-linux.so.2@/tools/lib/ld-linux.so.2@g' \ 26 sed -e 's@/lib/ld-linux.so.2@/tools/lib/ld-linux.so.2@g' \ 28 27 $SPECFILE > tempspecfile 29 28 mv tempspecfile $SPECFILE 30 29 unset SPECFILE</userinput></screen></para> 31 30 32 <para>We recommend that you cut-and-paste the above rather than try and type it 33 all in. Or you can edit the specs file by hand if you want to: just replace 34 "/lib/ld-linux.so.2" with "/tools/lib/ld-linux.so.2" and "/lib/ld.so.1" with 35 "/tools/lib/ld.so.1".</para> 31 <para>We recommend that you cut-and-paste the above rather than try and type it 32 all in. Or you can edit the specs file by hand if you want to: just replace any 33 occurrence of "/lib/ld-linux.so.2" with "/tools/lib/ld-linux.so.2".</para> 34 35 <important><para>If you are working on a platform where the name of the dynamic 36 linker is something other than <filename>ld-linux.so.2</filename>, you 37 <emphasis>must</emphasis> substitute <filename>ld-linux.so.2</filename> with the 38 name of your platform's dynamic linker in the above commands. Refer back to the 39 "Toolchain technical notes" section if necessary.</para></important> 36 40 37 41 <para>Lastly, there is a possibility that some include files from the host -
chapter05/toolchaintechnotes.xml
r04a3351 rf57e3d1 123 123 <filename class="directory">/tools/lib</filename>. This last step is 124 124 <emphasis>vital</emphasis> to the whole process. As mentioned above, a 125 hard-wired path to a dynamic linker is embedded into every executable binary.126 You can inspect this by running:125 hard-wired path to a dynamic linker is embedded into every ELF shared 126 executable. You can inspect this by running: 127 127 <userinput>`readelf -l <name of binary> | grep interpreter`</userinput>. 128 128 By amending the GCC specs file, we are ensuring that every program compiled from -
chapter06/adjustingtoolchain.xml
r04a3351 rf57e3d1 18 18 source and build directories from the second pass in Chapter 5 or otherwise 19 19 accidentally deleted them or just don't have access to them, don't worry, all is 20 not lost. Just ignore th is step. The result will be that the next package,21 Binutils, will link against the Glibc libraries in20 not lost. Just ignore the above command. The result will be that the next 21 package, Binutils, will link against the Glibc libraries in 22 22 <filename class="directory">/tools</filename> rather than 23 23 <filename class="directory">/usr</filename>. This is not ideal, however, our … … 42 42 43 43 <para><screen><userinput>SPECFILE=/tools/lib/gcc-lib/*/*/specs 44 sed -e 's@/tools/lib/ld.so.1@/lib/ld.so.1@g' \ 45 -e 's@/tools/lib/ld-linux.so.2@/lib/ld-linux.so.2@g' \ 44 sed -e 's@/tools/lib/ld-linux.so.2@/lib/ld-linux.so.2@g' \ 46 45 $SPECFILE > newspecfile 47 46 mv newspecfile $SPECFILE … … 51 50 before, it is a good idea to check the specs file to ensure the intended 52 51 changes were actually made.</para> 52 53 <important><para>If you are working on a platform where the name of the dynamic 54 linker is something other than <filename>ld-linux.so.2</filename>, you 55 <emphasis>must</emphasis> substitute <filename>ld-linux.so.2</filename> with the 56 name of your platform's dynamic linker in the above commands. Refer back to the 57 "Toolchain technical notes" section if necessary.</para></important> 53 58 54 59 <caution><para>It is imperative at this point to stop and ensure that the -
chapter06/gcc-inst.xml
r04a3351 rf57e3d1 25 25 26 26 <para>The second patch here suppresses the installation of libiberty from GCC, 27 as we will use the one provided by binutils instead.</para> 27 as we will use the one provided by binutils instead. Be careful 28 <emphasis>not</emphasis> to apply the GCC specs patch from Chapter 5 29 here.</para> 28 30 29 31 <para>The GCC documentation recommends building GCC outside of the source -
index.xml
r04a3351 rf57e3d1 4 4 5 5 6 <!ENTITY version "2003100 6">7 <!ENTITY releasedate "October 6th, 2003">6 <!ENTITY version "20031007"> 7 <!ENTITY releasedate "October 7th, 2003"> 8 8 <!ENTITY nbsp " "> 9 9
Note:
See TracChangeset
for help on using the changeset viewer.