Changeset 15b6ed4
- Timestamp:
- 01/21/2004 10:15:22 PM (20 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_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:
- 5618bb7
- Parents:
- d12fdb1
- Files:
-
- 8 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter01/changelog.xml
rd12fdb1 r15b6ed4 56 56 </listitem> 57 57 58 <listitem><para>January 21st, 2004 [alex]: Chapters 2 and 6 - Making a few 59 extra cross references.</para></listitem> 60 58 61 <listitem><para>January 19th, 2004 [greg]: Upgraded to Glibc-2.3.3, Kbd-1.12, 59 62 Perl-5.8.3 and Shadow-4.0.4.1.</para></listitem> -
chapter02/aboutsbus.xml
rd12fdb1 r15b6ed4 13 13 14 14 <para>It works like this: the first package you compile in this book is the 15 statically linked Binutils in Chapter 5, and the time it takes to compile this16 package is what we call the "Static Binutils Unit" or "SBU". All other compile 17 times will be expressed relative to this time.</para>15 statically linked Binutils in<xref linkend="chapter05"/>, and the time it 16 takes to compile this package is what we call the "Static Binutils Unit" or 17 "SBU". All other compile times will be expressed relative to this time.</para> 18 18 19 19 <para>For example, the time it takes to build the static version of GCC is -
chapter02/abouttestsuites.xml
rd12fdb1 r15b6ed4 4 4 5 5 <para>Most packages provide a test suite. Running the test suite for a newly 6 built package is generally a good idea as it can provide a nice sanity check7 that everything compiled correctly. A test suite that passes its set of 8 checksusually proves that the package is functioning mostly as the developer6 built package is generally a good idea, as it can provide a nice sanity check 7 that everything compiled correctly. A test suite that passes its set of checks 8 usually proves that the package is functioning mostly as the developer 9 9 intended. It does not, however, guarantee that the package is totally bug 10 10 free.</para> … … 14 14 library) -- are of the utmost importance due to their central role in a 15 15 properly functioning system. But be warned, the test suites for GCC and Glibc 16 can take a very long period of time to complete, especially on slower 17 hardware.</para> 16 can take a very long time to complete, especially on slower hardware.</para> 18 17 19 18 <para>Experience has shown us that there is little to be gained from running 20 the test suites in Chapter 5. There can be no escaping the fact that the host 21 system always exerts influence on the Chapter 5 tests, often causing weird and 22 inexplicable failures. Not only that, the tools built in Chapter 5 are 23 temporary and eventually discarded. For the average reader of this book we 24 recommend not to run the Chapter 5 test suites. The instructions for running 25 the Chapter 5 test suites are still provided for the benefit of testers and 26 developers but they are strictly optional for everyone else.</para> 19 the test suites in <xref linkend="chapter05"/>. There can be no escaping the 20 fact that the host system always exerts influence on the tests in that chapter, 21 often causing weird and inexplicable failures. Not only that, the tools built 22 in <xref linkend="chapter05"/> are temporary and eventually discarded. For the 23 average reader of this book we recommend <emphasis>not</emphasis> to run the 24 test suites in <xref linkend="chapter05"/>. The instructions for running those 25 test suites are still provided for the benefit of testers and developers, but 26 they are strictly optional for everyone else.</para> 27 27 28 <para>As you progress through the book and encounter the build commands to29 run the various test suites, we'll guide you on the relative importance of 30 the test suite in question so that you can decide for yourself whether to 31 run itor not.</para>28 <para>As you progress through the book and encounter the commands to run the 29 various test suites, we'll guide you on the relative importance of the test 30 suite in question, so that you can decide for yourself whether to run that one 31 or not.</para> 32 32 33 33 <note><para>A common problem when running the test suites for Binutils and GCC 34 is running out of pseudo terminals (PTYs for short). The symptom is an unusually35 high number of failing tests. This can happen for any number of reasons. Most 36 likely is that the host system doesn't have the <emphasis>devpts</emphasis> file37 system set up correctly. We'll discuss this in more detail later on in Chapter 38 5.</para></note>34 is running out of pseudo terminals (PTYs for short). The symptom is an 35 unusually high number of failing tests. This can happen for a number of 36 reasons. Most likely is that the host system doesn't have the 37 <emphasis>devpts</emphasis> file system set up correctly. We'll discuss this in 38 more detail later on in <xref linkend="chapter05"/>.</para></note> 39 39 40 40 </sect1> -
chapter06/chapter06.xml
rd12fdb1 r15b6ed4 274 274 use the group's name.</para> 275 275 276 <para> Lastly, we re-login to the chroot environment. User name and group name277 resolution will start working immediately after the 278 <filename>/etc/passwd</filename> and <filename>/etc/group</filename> files are 279 created, because we installed a full Glibc in Chapter 5. This will get rid of 280 the <quote>I have no name!</quote> prompt.</para>276 <para>To get rid of the "I have no name!" prompt, we will start a new shell. 277 Since we installed a full Glibc in <xref linkend="chapter05"/>, and have just 278 created the <filename>/etc/passwd</filename> and 279 <filename>/etc/group</filename> files, user name and group name resolution 280 will now work.</para> 281 281 282 282 <screen><userinput>exec /tools/bin/bash --login +h</userinput></screen> … … 330 330 331 331 <note><para>If you somehow missed the earlier warning to retain the Binutils 332 source and build directories from the second pass in Chapter 5 or otherwise333 accidentally deleted them or just don't have access to them, don't worry, all is 334 not lost. Just ignore the above command. The result will be that the next 335 package, Binutils, will link against the Glibc libraries in 336 <filename class="directory">/tools</filename> rather than 337 <filename class="directory">/usr</filename>. This is not ideal, however, our 338 testing has shown that the resulting Binutils program binaries should be332 source and build directories from the second pass in 333 <xref linkend="chapter05"/>, or otherwise accidentally deleted them or just 334 don't have access to them, don't worry, all is not lost. Just ignore the above 335 command. The result will be that the next package, Binutils, will link against 336 the Glibc libraries in <filename class="directory">/tools</filename> rather 337 than <filename class="directory">/usr</filename>. This is not ideal, however, 338 our testing has shown that the resulting Binutils program binaries should be 339 339 identical.</para></note> 340 340 -
chapter06/gcc.xml
rd12fdb1 r15b6ed4 38 38 39 39 <note><para>Be careful <emphasis role="strong">not</emphasis> to apply the GCC 40 Specs patch from Chapter 5here.</para></note>40 Specs patch from <xref linkend="chapter05"/> here.</para></note> 41 41 42 42 <para>First apply the No-Fixincludes patch that we also used in the previous … … 96 96 <xref linkend="ch06-adjustingtoolchain"/> and repeat the check. If the results 97 97 are wrong, then most likely you erroneously applied the GCC Specs patch from 98 Chapter 5.</para></note>98 <xref linkend="chapter05"/>.</para></note> 99 99 100 100 </sect2> -
chapter06/makedev.xml
rd12fdb1 r15b6ed4 49 49 information.</para> 50 50 51 <para>Additionally, if you were unable to mount the devpts filesystem earlier in52 the "Mounting the proc and devpts file systems" section, now is the time to 53 try the alternatives. If your kernel supports the devfs file system, run the 54 following command to mountdevfs:</para>51 <para>Additionally, if you were unable to mount the devpts filesystem earlier 52 in <xref linkend="ch06-proc"/>, now is the time to try the alternatives. If 53 your kernel supports the devfs file system, run the following command to mount 54 devfs:</para> 55 55 56 56 <screen><userinput>mount -t devfs devfs /dev</userinput></screen> -
chapter06/mountproc.xml
rd12fdb1 r15b6ed4 48 48 <emphasis>devfs</emphasis> is listed there, then we'll be able to work around 49 49 the problem by mounting the host's devfs file system on top of the new 50 <filename>/dev</filename> structure which we'll create later on in the 51 "Creating devices (Makedev)" section. If devfs was not listed, do not worry50 <filename>/dev</filename> structure which we'll create later on in the section 51 on <xref linkend="ch06-MAKEDEV"/>. If devfs was not listed, do not worry 52 52 because there is yet a third way to get PTYs working inside the chroot 53 environment. We'll cover this shortly in the aforementioned Makedev54 section.</para>53 environment. We'll cover this shortly in the aforementioned 54 <xref linkend="ch06-MAKEDEV"/> section.</para> 55 55 56 56 <para>Remember, if for any reason you stop working on your LFS, and start again -
chapter07/introduction.xml
rd12fdb1 r15b6ed4 3 3 <?dbhtml filename="introduction.html" dir="chapter07"?> 4 4 5 <para>This chapter will set up the bootscripts that you installed in chapter6 6. Most of these scripts will work without needing to modify them, but a7 few do require additional configuration files set up as they deal with8 hardwaredependent information.</para>5 <para>This chapter will set up the bootscripts you installed in the previous 6 chapter. Most of these scripts will work without needing to modify them, but a 7 few do require additional configuration files, as they deal with hardware 8 dependent information.</para> 9 9 10 10 </sect1>
Note:
See TracChangeset
for help on using the changeset viewer.