Problems compiling current CVS under cygwin.

[Neil Booth]

Andy Hare wrote:-

> Neil,
> 
> I put a trace into the cppfiles.c function open_file to print out the
> include files as they are opened and I found that there was indeed a
> recursive set of include files as shown by the output below.

Sorry, I should have mentioned in case you weren't aware that you can
get a helpful include trace with the -H option to cpp (try it on
something you know that works).  If the size of the array in
scan-decls were more than 200, CPP would complain about possible
infinite recursion anyway.  It might be an idea to expand the limit in
fix-header so that problems such as yours show up as a CPP diagnostic
rather than a segfault.

> $ /build/arm/gcc/gcc/fix-header dirent.h
> /xgcc-arm/gnu/arm-elf/sys-include/dirent.h
> /build/arm/gcc/gcc/include/dirent.h -D__STDC__=0 -D__cplusplus -/build/arm/g
> cc/gcc/include -I/xgcc-arm/gnu/arm-elf/sys-include
> Filename for open </xgcc-arm/gnu/arm-elf/sys-include/dirent.h>
> Filename for open </build/arm/gcc/gcc/include/sys/dirent.h>
> Filename for open </xgcc-arm/gnu/arm-elf/sys-include/sys/dirent.h>
>
> The last of these files then loaded <dirent.h> again. According to the blurb
> in the file it should load any dirent.h that is lying around and should fail
> if one can't be found. Of course since <dirent.h> was what started this off,
> it is picked up again and the loop continues. I have removed the <dirent.h>
> from the last file and the problem went away. This will do as a fix for my
> problem but fix-header should probably be fixed so that this recursive issue
> is tagged and some useful failure message printed so that anyone else
> finding the problem gets a clue about what is happening. The easiest way of
> doing this would be to put a check into scan_decls for the extern_C_braces
> array being exceeded and then trigger a failure after printing some
> information on the current file open.

Hmm.  I'm not a fix-header expert by any stretch of the imagination
;-) Maybe someone who is could chime up.  I suspect the issue is one
of the following:

1) Invalid configuration when you configure the GCC build process.

2) Something bogus in fix-header / fix-includes / all that other magic
   that I don't claim to really understand.

I suggest a quick fix is to put include guards around the dirent.h
that comes with your (cygwin?) system.  Meanwhile, would you submit a
bug report in GNATS under the "target" category?  Obviously you don't
need to give preprocessed source as that would be useless; just give
as complete a description of your environment as you can, how you
configured GCC and what went wrong.

Thanks,

Neil.