- Timestamp:
- 02/14/2004 02:53:12 PM (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, 12.2, 12.2-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/loongarch-12.2, xry111/mips64el, xry111/multilib, xry111/pip3, xry111/rust-wip-20221008, xry111/update-glibc
- Children:
- 21308e2
- Parents:
- cd1ddd7
- Location:
- chapter05
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter05/chapter05.xml
rcd1ddd7 rc3dc67c 156 156 157 157 <para>This is important for the reasons mentioned above. It also demonstrates 158 that GCC's configure script does not search the $PATH directories to find which158 that GCC's configure script does not search the PATH directories to find which 159 159 tools to use. However, during the actual operation of <command>gcc</command> 160 160 itself, the same search paths are not necessarily used. You can find out which … … 170 170 building Glibc are the compiler, binary tools and kernel headers. The compiler 171 171 is generally no problem as Glibc will always use the <command>gcc</command> 172 found in a $PATH directory. The binary tools and kernel headers can be a little172 found in a PATH directory. The binary tools and kernel headers can be a little 173 173 more troublesome. Therefore we take no risks and use the available configure 174 174 switches to enforce the correct selections. After the run of … … 526 526 <command>cc</command>. If this works it means the 527 527 <filename class="symlink">/tools/bin/cc</filename> symlink is missing. Revisit 528 <xref linkend="ch-tools-gcc-pass1"/> and fix the symlink. Second, ensure your $PATH528 <xref linkend="ch-tools-gcc-pass1"/> and fix the symlink. Second, ensure your PATH 529 529 is correct. You can check this by running <userinput>echo $PATH</userinput> and 530 530 verifying that <filename class="directory">/tools/bin</filename> is at the head 531 of the list. If the $PATH is wrong it could mean you're not logged in as user531 of the list. If the PATH is wrong it could mean you're not logged in as user 532 532 <emphasis>lfs</emphasis> or something went wrong back in 533 533 <xref linkend="ch-tools-settingenviron"/>. Third, something may have gone wrong with … … 587 587 588 588 <para>Take care <emphasis>not</emphasis> to use 589 <emphasis>--strip-unneeded</emphasis> on the libraries -- they would be 590 destroyed and you would have to build Glibc all over again.</para> 589 <emphasis>--strip-unneeded</emphasis> on the libraries -- the static ones 590 would be destroyed and you would have to build the three toolchain packages 591 all over again.</para> 591 592 592 593 <para>To save another couple of megabytes, you can throw away all the -
chapter05/gettext.xml
rcd1ddd7 rc3dc67c 23 23 24 24 <para>(If you insist on testing the results, then issue: <userinput>make 25 check</userinput>. This takes a very long time, around 6SBUs. Moreover, the25 check</userinput>. This takes a very long time, around 7 SBUs. Moreover, the 26 26 Gettext test suite is known to experience failures under certain host 27 27 conditions -- for example when it finds a Java compiler on the host (but an
Note:
See TracChangeset
for help on using the changeset viewer.