Removed the note to link m4 statically outside of chroot. We don't know

if this is still true with the current Glibc-2.2.4 we're using.


git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@1094 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

chapter06/m4-inst.xml

@@ -7,32 +7,5 @@
 <userinput>make &amp;&amp;</userinput>
 <userinput>make install</userinput></screen></para>
 
-<para>If the base system is running a 2.0 kernel and the Glibc version is
-2.1 then you will most likely get problems executing M4 in the
-chroot'ed environment due to incompatibilities between the M4 program,
-Glibc-2.1 and the running 2.0 kernel. If you have problems executing the 
-m4 program in the chroot'ed environment (for example when you install 
-the autoconf and automake packages) you'll have to exit the chroot'ed 
-environment and compile M4 statically. This way the binary is linked 
-against Glibc 2.0 (if he runs kernel 2.0, Glibc version is 2.0 as 
-well on a decent system. Kernel 2.0 and Glibc-2.1 don't mix very well) 
-and won't give any problems.</para>
-
-<para>To create a statically linked version of M4, execute the following
-commands:</para>
-
-<para><screen><userinput>logout</userinput>
-<userinput>cd $LFS/usr/src/m4-1.4</userinput>
-<userinput>./configure --prefix=/usr</userinput>
-<userinput>make LDFLAGS=-static</userinput>
-<userinput>make prefix=$LFS/usr install</userinput></screen></para>
-
-<para>Now the chroot'ed environment can be re-entered and the
-next package an be installed. If M4 should be re-compiled dynamically,
-this can be done after having rebooted into the LFS system 
-rather than chrooting into it.</para>
-
-<para><screen>&c6-chrootcmd;</screen></para>
-
 </sect2>