[lfs-support] LFS 7.6 Ch. 6.17 GCC: make error
zarniwhoop at ntlworld.com
Tue Mar 3 10:19:50 PST 2015
On Tue, Mar 03, 2015 at 03:42:05PM +0100, ZyaX wrote:
> 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>
I think you are correct that linux/limit.h is the problem. Looking
at one of my x86_64 7.6 logs, the linux headers installed
/usr/include/linux/limits.h [ as well as a lot of other files there,
and directories /usr/include/asm /usr/include/asm-generic
/usr/include/drm /usr/include/mtd /usr/include/rdma
/usr/include/scsi /usr/include/sound /usr/include/uapi
/usr/include/video /usr/include/xen ]. Of course glibc then
puts more files into some of those directories.
> 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.
I think these fragments either get deleted immediately, or perhaps
they are somewhere in /tmp.
> 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.
Did you remove the untarred headers after installing them to /tools
in chapter 5, and then use freshly extracted source for chapter 6 ?
I do not see why that would make any difference to the headers
(unlike several other packages), but I'll ask anyway.
Apart from that, I guess smething went wrong in
find dest/include \( -name .install -o -name ..install.cmd \) -delete
cp -rv dest/include/* /usr/include
Maybe you missed the copy to /usr/include ?
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
More information about the lfs-support