Greetings
I have seen the same problem listed in other posts and can not get my head around why it is happening. Also the other threads seem to end abruptly which isn`t helping me. The problem occurs in Section 6.14/ GCC-3.4.3


In file included from ../../gcc-3.4.3/gcc/crtstuff.c:62:
../../gcc-3.4.3/gcc/tsystem.h:79:19: stdio.h: No such file or directory
../../gcc-3.4.3/gcc/tsystem.h:82:23: sys/types.h: No such file or directory
../../gcc-3.4.3/gcc/tsystem.h:85:19: errno.h: No such file or directory
../../gcc-3.4.3/gcc/tsystem.h:92:20: string.h: No such file or directory
../../gcc-3.4.3/gcc/tsystem.h:93:20: stdlib.h: No such file or directory
../../gcc-3.4.3/gcc/tsystem.h:94:20: unistd.h: No such file or directory
In file included from /sources/gcc-build/gcc/include/syslimits.h:7,
from /sources/gcc-build/gcc/include/limits.h:11,
from ../../gcc-3.4.3/gcc/tsystem.h:97,
from ../../gcc-3.4.3/gcc/crtstuff.c:62:
/sources/gcc-build/gcc/include/limits.h:122:61: limits.h: No such file ordirectory
In file included from ../../gcc-3.4.3/gcc/crtstuff.c:62:
../../gcc-3.4.3/gcc/tsystem.h:100:18: time.h: No such file or directory
make[1]: *** [crtbegin.o] Error 1
make[1]: Leaving directory `/sources/gcc-build/gcc'
make: *** [all-gcc] Error 2

To check the version of gcc used the following checks were suggested

AS CHROOT ON LFS

root:/sources/gcc-build# gcc -v dummy.c
gcc: dummy.c: No such file or directory
Reading specs from /tools/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/tools --
libexecdir=/tools/lib --with-local-prefix=/tools --enable-
clocale=gnu --enable-shared --enable-threads=posix --enable-
__cxa_atexit --enable-languages=c,c++ --disable-libstdcxx-pch
Thread model: posix
gcc version 3.4.3

root:/sources/gcc-build# type -p gcc
/tools/bin/gcc
root:/sources/gcc-build# type -p cc
/tools/bin/cc

AS USER ON HOST

[michael@localhost ~]$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)

[michael@localhost ~]$ type -p gcc
/usr/bin/gcc

[michael@localhost ~]$ type -p cc
/usr/bin/cc



AS USER lfs ON HOST

[michael at localhost ~]$ su - lfs
Password:
lfs:~$ echo $PATH
/tools/bin:/bin:/usr/bin
lfs:~$ gcc -v
Reading specs from /mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-
gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/tools --
libexecdir=/tools/lib --with-local-prefix=/tools --enable-
clocale=gnu --enable-shared --enable-threads=posix --enable-
__cxa_atexit --enable-languages=c,c++ --disable-libstdcxx-pch
Thread model: posix
gcc version 3.4.3
lfs:~$ type -p gcc
/tools/bin/gcc
lfs:~$ type -p cc
/tools/bin/cc


The files exist in $LFS/usr/include. I have used new build directories for gcc and binutils at each stage. Can anyone help interpret these results, is gcc looking on the $LFS partition or trying to get back to Fedora? (looks OK to me) Is that anything to do with the problem?
Thanks Michael

Looks as though I'm having the same problem as you.
One difference I noticed on my system is that there is an -isystem
(system includes?) flag on the command line for that particular
file and not one on any of the others. What's more, the directory
referenced by -isystem (/usr/i686-pc-linux-gnu/sys-include)
appears to be missing.

I'll investigate a bit further, and post my findings (if any)
failing that, I'm going to start over and make sure I don't miss
anything!

Chay

Correct me if I'm wrong but these are headers provided by glibc. Go to /usr/include (in chroot) and check to see if you can find any of these headers. If not, reinstall glibc, then try to build gcc again. If that doesn't work then come back here.

Hope you get it sorted.

Couldn't find any headers where it was searching, and didn't want to copy
over something that may have been potentially incompatible.

Starting the LFS build from scratch resolved the problem
(so I guess I missed something, somewhere)