On 1/27/2018 6:17 PM, Ken Moffat wrote:
On Sat, Jan 27, 2018 at 05:48:02PM -0500, Baho Utot wrote:
On 1/27/2018 11:41 AM, Maxwell Huenink wrote:
After building GCC in step 6.20 there were several steps to ensure that
the new GCC was installed correctly. Starting at "Verify the compiler is
serching for the correct header files:", I failed to get the output that
the book says I should get.
Rather than getting:
|#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include /usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include-fixed /usr/include|
I got
root:/sources/gcc-7.2.0/build# grep -B4 '^ /usr/include' dummy.log
ignoring nonexistent directory
"/tools/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory "/tools/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include
I also did not get the correct search paths in the following step, which
should have been:
|SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/local/lib64") SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64") SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib") SEARCH_DIR("/usr/lib");
|
|But instead I got:
|
root:/sources/gcc-7.2.0/build# grep 'SEARCH.*/usr/lib' dummy.log |sed
's|; |\n|g'
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib");
I have already run "make install" and don't know what my next step
should be.
I have been getting this too. I am currently working on this and I think it
is related to the symlink in
6.9.1. Installation of Glibc
First create a compatibility symlink to avoid references to /tools in our
final glibc:
ln -sfv /tools/lib/gcc /usr/lib
I have not confirmed this as I have not tried a rebuild which will be soon.
I think *omitting* that symlink causes the problem. When I was
doing test builds at the beginning of this month re Meltdown I
thought to myself "I can reuse this script to update the finished
system if I remove that symlink", so I removed it and got failures
in the sanity checks in a new LFS build.
I don't think they were identical to what Maxwell reported, but for
me the cause of the problem was obvious so I started over.
I've now built 3 minimal systems to time the PTI/retpoline changes,
and then two real systems (one complete, one now part-way through my
desktop packages) with that symlink, and on all of them the sanity
checks were fine.
I've also created a separate script for updating gcc on a completed
system (and used it to update the host system before building the
third minimal test system) *without* that symlink.
For Maxwell's problem I don't think there is any way to recover, but
maybe someboy else knows of a workaround.
ĸen
In my case the /usr/lib/gcc is very wrong as it has /tools/lib/gcc files
in it like the following:
ls /usr/lib/gcc
x86_64-lfs-linux-gnu
which is from the cross building early in chapter 5.
I am currently looking into how that may have occurred and have a
building in progress so I can track it down.
Might have some answers in the morning time will tell
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
