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
This commit is contained in:
Gerard Beekmans 2001-08-28 22:31:24 +00:00
parent c54baff77f
commit 110969fabc

View File

@ -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>