Armin K. wrote:
On Sat, 2018-02-03 at 02:56 +0000, [email protected]
wrote:
Author: bdubbs
Date: Fri Feb 2 18:56:41 2018
New Revision: 11359
Log:
Update to glibc-2.27.
@@ -56,16 +56,21 @@
store their runtime data in the FHS-compliant locations:</para>
<screen><userinput remap="pre">patch -Np1 -i ../&glibc-fhs-
patch;</userinput></screen>
-
+<!--
<para>Fix a minor security issue with glob functions:</para>
<screen><userinput remap="pre">patch -Np1 -i ../&glibc-glob-
patch;</userinput></screen>
-
+-->
<para>First create a compatibility symlink to avoid references
to /tools in
our final glibc:</para>
<screen><userinput remap="pre">ln -sfv /tools/lib/gcc
/usr/lib</userinput></screen>
+ <para>Now work around a problem caused by a hard-coded path to
an
+ executable program:</para>
+
+<screen><userinput remap="pre">ln -sfv /tools/bin/m4
/usr/bin</userinput></screen>
+
This is wrong. M4 is in chapter 5, but it is built AFTER Bison.
Ideally, you should move M4 before Bison, so this wouldn't be needed.
The problem is that bison seems to have /usr/bin hard coded. Indeed,
running strings on /tools/bin/bison shows /usr/bin/m4. Setting the
symlink in Chapter 6 works around the issue until m4 is installed in
Chapter 6.
I suppose we could remove the symlink and move m4 up to just before glibc.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
