Silly branch compile failure, stage 1
Kaveh R. Ghazi
ghazi@caip.rutgers.edu
Mon Apr 2 12:05:00 GMT 2001
> 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
More information about the Gcc-bugs
mailing list