This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/17508] Bootstrap fails to find system headers: sys/m_types.h, sys/limits.h
- From: "skunk at iskunk dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 15 Sep 2004 22:57:20 -0000
- Subject: [Bug target/17508] Bootstrap fails to find system headers: sys/m_types.h, sys/limits.h
- References: <20040915192709.17508.skunk@iskunk.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From skunk at iskunk dot org 2004-09-15 22:57 -------
The AIX stdio.h and sys/types.h headers do seem to follow the correct convention
when pulling in limits.h and sys/m_types.h:
----(begin AIX stdio.h excerpt)----
#ifdef _ALL_SOURCE
#ifndef _H_LIMITS
#include <sys/limits.h> /* limits.h not allowed by Posix.1a. Must be in
_ALL_SOURCE */
#endif
----(end AIX stdio.h excerpt)----
----(begin AIX sys/types.h excerpt)----
#ifdef _ALL_SOURCE
typedef struct _quad { int val[2]; } quad;
#ifndef _H_M_TYPES
#include <sys/m_types.h> /* machine-dependent type definitions */
#endif
----(end AIX sys/types.h excerpt)----
(The #include directives are identical in the fixincluded files)
My impression was that the options passed to the aforementioned invocation of
xgcc were causing the compiler not to look in /usr/include at all, such that
these two basic #include directives would fail.
I suspect that the fix would be simply to copy these two sub-headers into the
GCC build tree (and have "make install" ignore them completely). When the
resulting GCC is invoked, the fixincluded stdio.h and sys/types.h should find
these files trivially in /usr/include. It is only in the GCC build environment
that the problem arises.
My earlier workaround (symlinking the files appropriately under
$top_builddir/gcc/include) has allowed the build to proceed without another
hitch so far. The build is taking place on an NFS mount, and so it will be
several hours before it finishes, but I will be happy to report back here either
with success, or some other issue related to this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17508