Re: Silly branch compile failure, stage 1

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Neil Booth <neil@daikokuya.demon.co.uk>
 > 
 > Kaveh R. Ghazi wrote:-
 > 
 > > This is the crucial bit, the tests are spuriously failing because they
 > > can't find these include files.  The -I flags passed in look strange.
 > > 
 > > I think you need to look at why these don't match up.  Are you by
 > > chance building in a subdirectory of the srcdir?  (I don't think that
 > > is supported.)
 > 
 > I build with my directory hierarchy as follows (and always have done):-
 > 
 > gcc -- gcc -- cp
 > 	   -- f
 >            -- objc
 > 	   -- (etc)
 >     -- build
 >     -- fastjar
 >     -- boehm-gc
 >     -- (etc)
 > 
 > and build from the "build" directory.  Thus, my configure command starts
 > with
 > 
 > ../configure --options
 > 
 > This has worked for over a year, until just now, so I hope it
 > hasn't become unsupported.  Besides, it's working on mainline
 > still.  Does this count as building in a subdirectory of the
 > srcdir?  It's a subdirectory of the toplevel "gcc", along with
 > boehm-gc and stuff.
 > Neil.

Well, *I* haven't done anything to suddenly break this, but someone
else may have.  But I do believe what you are doing is exactly the
type of action that isn't supposed to work.  My info may be out of
date, and/or it may have worked by accident up until now.  I don't
know.

Anyway given your directory structure, I can't figure out why this
particular action failed.  If you're in gcc/build/gcc and have
-I../../gcc, then test should have found system.h/gansidecl.h AFAICT.

Are any of the DECL tests passing, or do they all fail?
How about getrusage which is in the same autoconf block as
getrlimit/setrlimit?  What about the non-sys/resource.h tests?

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions