Armin K. wrote:
On Sun, 2018-02-04 at 11:33 +0100, Pierre Labastie wrote:
On 04/02/2018 09:02, Armin K. wrote:
On Sat, 2018-02-03 at 18:11 -0600, Bruce Dubbs wrote:
Armin K. wrote:
On Sat, 2018-02-03 at 02:56 +0000, email@example.com
Date: Fri Feb 2 18:56:41 2018
New Revision: 11359
Update to glibc-2.27.
@@ -56,16 +56,21 @@
store their runtime data in the FHS-compliant
<screen><userinput remap="pre">patch -Np1 -i ../&glibc-fhs-
<para>Fix a minor security issue with glob
<screen><userinput remap="pre">patch -Np1 -i ../&glibc-
<para>First create a compatibility symlink to avoid
to /tools in
our final glibc:</para>
<screen><userinput remap="pre">ln -sfv /tools/lib/gcc
+ <para>Now work around a problem caused by a hard-coded
+ executable program:</para>
+<screen><userinput remap="pre">ln -sfv /tools/bin/m4
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
The problem is that bison seems to have /usr/bin hard
running strings on /tools/bin/bison shows /usr/bin/m4. Setting
symlink in Chapter 6 works around the issue until m4 is installed
I suppose we could remove the symlink and move m4 up to just
It doesn't hardcode anything to /usr/bin, but rather to the path of
m4 executable found during ./configure. Because there's no
/tools/bin/m4, it finds /usr/bin/m4 from the host, and hardcodes
If there was /tools/bin/m4, it would hardcode that instead. Just
m4, eg, before ncurses in chapter 5 and see for yourself.
Just out of curiosity, why not just before bison?
It was an example. It matters not where it is, just that it's before
bison. I guess I came up with that example so the alphabetic ordering
is not disrupted. On my end, bison is the last package I install in
OK, I moved m4 in Chapter 5 and removed the symlink in my sandbox. I will
commit it after testing with the next package updates. It may be a few days.
Unsubscribe: See the above information page