Re: Problems compiling current CVS under cygwin.

["Andy Hare" <ahare at btinternet dot com>]

Neil,

I will put something into GNATS tomorrow when I have a bit more time.

Cheers for the help.
Andy Hare
www.ahare.btinternet.co.uk

----- Original Message -----
From: "Neil Booth" <neil@daikokuya.demon.co.uk>
To: "Andy Hare" <ahare@btinternet.com>
Cc: "gcc-bugs" <gcc-bugs@gcc.gnu.org>
Sent: Thursday, November 29, 2001 10:30 PM
Subject: Re: Problems compiling current CVS under cygwin.


> 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 i
ssue
> > 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.