Ron McCall
Wed Dec 21 19:47:00 GMT 2005

On Sun, Dec 18, 2005 at 10:42:33PM -0800, Dan Kegel wrote:
> I have a good idea already (I think the patch mentions it).
> But a patch is always welcome.

Okay, I've made some progress on this issue.  The problem occurs during
the final gcc "make all" when it tries to fix the system headers and you
get the following error message (with environment variables substituted
to aid in readability):

The directory that should contain system headers does not exist:

where $VERSION is the GCC version number (e.g. 3.4.1).

As you mentioned in your message in the fix-fixincl.patch patches, the
directory $PREFIX/lib/gcc/$TARGET/$VERSION does not yet exist (it is
created during "make install") but the system header directory
($PREFIX/$TARGET/sys-include) was indeed created during final gcc
configure.  So, if we create the $PREFIX/lib/gcc/$TARGET/$VERSION
directory prior to building the final gcc, everything works.  I have
verified that (for this particular combination of tools).

Do all versions of gcc that are currently being supported have the
directory $PREFIX/lib/gcc/$TARGET/$VERSION?  gcc 3.2.3 definitely does
and I'm pretty sure 3.1 did as well.  How about 3.0 and 2.95?  Should I
build some of these myself to determine that?  Seems like a native build
of gcc is sufficient to determine this as it uses the same style
directories as a cross version (in which case $TARGET==$HOST).

The $VERSION part is slightly tricky.  It appears that $GCC_DIR is
typically of the form gcc-$VERSION or gcc-$VERSION-$DATE and thus
$VERSION could easily be extracted from $GCC_DIR.  Is this OK?  Or,
would it be safer/better to have the various gcc*.dat files define a new
variable something like say, $GCC_VERSION, to avoid relying on the
format of $GCC_DIR?


Want more information?  See the CrossGCC FAQ,
Want to unsubscribe? Send a note to

More information about the crossgcc mailing list