On 3/1/15, Ken Moffat <[email protected]> wrote: > The best way to find the relevant part of config.log is to use > another term (as root on the host - that way, you have a full > toolkit) and cd to /mnt/lfs/sources/gcc-build. > > Gcc is among the packages which run configure in many subdirectories, > each with its own config.log. This one looks as if it is in the > top-level directory, but you could run 'find . -name config.log | > xargs ls -l' to check. > > If there is more than one, grep them for 'fails sanity check'. When > you know which config.log is the important one, open it in 'less' > and seach for 'fails sanity check', [ that will be > /fails\ sanity\ check > if you are not aware ]. > > Then look at the lines above that. You should see configure > creating a program fragment, trying to run it, getting one or more > errors, and then producing the 'fails sanity check' message. It is > the error(s) which will point to what is wrong.
Thanks. I found that the pertinent config.log was gcc-build/x86_64-unknown-linux-gnu/libgcc/config.log. It was the only one of around ten files that had the sought error message. Inspecting the part with 'fails sanity check' gives a message above that repeats around 9 times and consists of: configure:3938: /lib/cpp conftest.c /sources/gcc-4.9.1/libgcc/configure: line 1459: /lib/cpp: No such file or directory configure:3938: $? = 127 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU C Runtime Library" | #define PACKAGE_TARNAME "libgcc" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "GNU C Runtime Library 1.0" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "http://www.gnu.org/software/libgcc/"; | /* end confdefs.h. */ | #ifdef __STDC__ | # include <limits.h> | #else | # include <assert.h> | #endif | Syntax error configure:3968: error: in `/sources/gcc-build/x86_64-unknown-linux-gnu/libgcc': configure:3971: error: C preprocessor "/lib/cpp" fails sanity check Though I'm not sure where one message ends and the next begins. But going up all the way it starts out with configure(i.e. /sources/gcc-4.9.1/libgcc/configure) checking for the C preprocessor: configure:3848: checking how to run the C preprocessor configure:3879: /sources/gcc-build/./gcc/xgcc -B/sources/gcc-build/./gcc/ -B/usr/x86_64-unknown-linux-gnu/bin/ -B/usr/x86_64-unknown-linux-gnu/lib/ -isystem /usr/x86_64-unknown-linux-gnu/include -isystem /usr/x86_64-unknown-linux-gnu/sys-include -E conftest.c In file included from /usr/include/bits/posix1_lim.h:160:0, from /usr/include/limits.h:143, from /sources/gcc-build/gcc/include-fixed/limits.h:168, from /sources/gcc-build/gcc/include-fixed/syslimits.h:7, from /sources/gcc-build/gcc/include-fixed/limits.h:34, from conftest.c:10: /usr/include/bits/local_lim.h:38:26: fatal error: linux/limits.h: No such file or directory #include <linux/limits.h> ^ compilation terminated. What first caught my eye was the included file conftest.c which didn't have a specified path, which would lead me to believe that it should be in the working directory. But that file doesn't exist anywhere for that matter. It seems like the file local_lim.h that refers to linux/limits.h puts the final nail in the coffin. Could it be that I didn't clean up my C headers when I installed them from the linux API package so that they point to the right places for the way LFS is set up? Although there are no such instructions for that package nor does it list the directory of that file as files that it installs. -- 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
