the ast build avoids this problem by (1) installing all ast headers in an include/ast subdir ($(INSTALLROOT)/include/ast) (2) using the iffe ``-X ast'' option to filter out all -Iast and -I*/ast options
I believe just eliminating the ``-I. -I../../../include'' options should work for your builds -- this basically says ``don't configure against any of my iffe generated headers'' if not then a final fallback is to locate the native stdio.h and use the iffe -O option; on most unix ``-O /usr/include/stdio.h'' should work but that will only eliminate <stdio.h> <=> iffe generated header clashes -- Glenn Fowler -- AT&T Research, Florham Park NJ -- On Fri, 30 May 2008 23:40:18 -0400 Jason Vas Dias wrote: > Hi - > I just joined this list today, and was wondering whether anyone might help : > Having built and installed vmalloc, cdt, sfio, in that order, in your > $X/Software > $AST directory, on a modern Linux or Solaris system, try: > $ cd $AST/Software/src/lib > $ mkdir -p test/features > $ cp -fp sfio/features/common test/features > $ cd test > $ ../../../bin/iffe - set cc $CC -I. -I../../../include : run features/sfio > > ast_common.h > > Now, in test/ast_common.h, you have a file that cannot be included: > > $ echo '#include "ast_common.h"' > t.c > $ gcc -Itest -I../../include -o t -c t.c > What has happened is that Software/include/stdio.h has '#include'd > ./ast_common.h > AS IT IS BEING GENERATED, as demonstrated by this > > $ ksh -x ../../../bin/iffe -d2 - set cc $CC -I. -I../../../include : run > features/sfio > ast_common.h _______________________________________________ ast-developers mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-developers
