When building gcc-3.4.3 or gcc-4.x into a clean $PREFIX,
the configure script happily copies the glibc include files from include to
sys-include;
here's the line from the log file (with $PREFIX instead of the real prefix):
Copying $PREFIX/i686-unknown-linux-gnu/include to
$PREFIX/i686-unknown-linux-gnu/sys-include
But later, when running fixincludes, it gives the error message
The directory that should contain system headers does not exist:
$PREFIX/lib/gcc/i686-unknown-linux-gnu/3.4.3/../../../../i686-unknown-linux-gnu/sys-include
Nevertheless, it continues building; the header files it installs in
$PREFIX/lib/gcc/i686-unknown-linux-gnu/3.4.3/include
do not include the boilerplate that would cause it to #include_next the
glibc headers in the system header directory.
Thus the resulting toolchain can't compile the following program:
#include <limits.h>
int x = PATH_MAX;
because its limits.h doesn't include the glibc header.
The problem is that gcc/Makefile.in assumes that
it can refer to $PREFIX/i686-unknown-linux-gnu with the path
$PREFIX/lib/../i686-unknown-linux-gnu, but
that fails because the directory $PREFIX/lib doesn't exist during 'make all';
it is only created later, during 'make install'. (Which makes this problem
confusing, since one only notices the breakage well after 'make install',
at which point the path configure complained about does exist, and has the
right stuff in it.)
I posted a proposed fix to
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00751.html
--
Summary: Building into empty PREFIX causes broken limits.h to be
installed
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22541
