|
@@ -43,13 +43,14 @@ memory space, disk space, and recompile time.</para>
|
|
|
|
|
|
<para>But if dynamic linking saves so much space, why then are we linking
|
|
<para>But if dynamic linking saves so much space, why then are we linking
|
|
the first two packages in this chapter statically? The reason is to make them
|
|
the first two packages in this chapter statically? The reason is to make them
|
|
-independent from the libraries on your host system. And the point in that is
|
|
|
|
-that, if you are pressed for time, you could skip the second passes over GCC
|
|
|
|
-and Binutils, and just use the static versions to compile the rest of this
|
|
|
|
-chapter and the first few packages in the next. As in the next chapter we
|
|
|
|
-will be chrooted to the LFS partition and your host system's Glibc won't be
|
|
|
|
-available, the programs from GCC and Binutils will need to be self-contained,
|
|
|
|
-that is statically linked.</para>
|
|
|
|
|
|
+independent from the libraries on your host system. The advantage is that, if
|
|
|
|
+you are pressed for time, you could skip the second passes over GCC and
|
|
|
|
+Binutils, and just use the static versions to compile the rest of this chapter
|
|
|
|
+and the first few packages in the next. In the next chapter we will be
|
|
|
|
+chrooted to the LFS partition and once inside the chroot environment, the host
|
|
|
|
+system's Glibc won't be available, thus the programs from GCC and Binutils
|
|
|
|
+will need to be self-contained, i.e. statically linked. However, we strongly
|
|
|
|
+advise <emphasis>against</emphasis> skipping the second passes.</para>
|
|
|
|
|
|
</sect1>
|
|
</sect1>
|
|
|
|
|