I report this as follow up to bug 21145 that has been wrongly marked as duplicate of 19601. The bug I reported is not AWK problem and thus it is not duplicate of the bug. My problem is caused by wrong includes search paths and headers with same names. I have installed autogen-5.6.4 which installs file /usr/local/include/options.h. File insn-conditions.c includes flags.h and that includes options.h that contains extern declarations for all flags. For some to me unknown reason both FreeBSD port gcc40 and my own builds of GCC 4.0.0 do add -I/usr/local/include to compiler's command line for insn-conditions.c and that prepends the path to search path for includes before GCC's include paths which makes the compiler include wrong options.h from /usr/local/include. I suspect that the -I/usr/local/include is added because of libiconv that is installed in in /usr/local prefix. Resulting command is this: gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE -I/usr/local/include -I. -Ibuild -I../../srcdir/gcc -I../../srcdir/gcc/build -I../../srcdir/gcc/../include -I../../srcdir/gcc/../libcpp/include -I/usr/local/include \ -o build/insn-conditions.o insn-conditions.c Note the double occurrence of -I/usr/local/include. I think this is genuine GCC configuratin scrip bug. Bootstrap compiler: wilx@amber2:::~/gcc-head/objdir/gcc> gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.2 [FreeBSD] 20040728 Configurations flags: ../srcdir/configure --disable-nls --enable-version-specific-runtime-libs --enable-dwarf2 --with-cpu=athlon-tbird --with-arch=athlon-tbird --with-system-zlib --disable-shared --enable-languages=c,c++,objc --disable-sjlj-exceptions --enable-shared=libstdc++ --enable-shared=libobjc --program-suffix=-4.0 --enable-objc-gc
Hmm, seems like autogen should not be calling its headers options.h, oh well.
Oh, the -I/usr/local/include is there twice, why? Can you attach the Makefile and config.log and config.status? There is a work around for this bug, is first compile FSF's GCC before 4.0.0 and then recompile GCC as the FSF's GCC all already include /usr/local/include as part of the include paths.
Created attachment 8795 [details] Makefile
Created attachment 8796 [details] config.status
Created attachment 8797 [details] config.log
Created attachment 8798 [details] gcc/config.log
Created attachment 8799 [details] gcc/Makefile
Created attachment 8800 [details] gcc/config.status
CPPFLAGS='-I/usr/local/include' Do you have CPPFLAGS set if so this is your bug and not GCC's configure bug.
Subject: Re: [4.0/4.1 Regression] Bootstrap, configuration problem and insn-conditions.c Nope, my environment is clean wrt/ compiler flags. On Mon, 2 May 2005, pinskia at gcc dot gnu dot org wrote: > > ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-02 13:52 ------- > CPPFLAGS='-I/usr/local/include' > > > Do you have CPPFLAGS set if so this is your bug and not GCC's configure bug. > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21268 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > You are on the CC list for the bug, or are watching someone who is. >
Subject: Re: [4.0/4.1 Regression] Bootstrap, configuration problem and insn-conditions.c That I don't have it set imho can be seen from config.log: ac_cv_env_CPPFLAGS_set= On Mon, 2 May 2005, pinskia at gcc dot gnu dot org wrote: > > ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-02 13:52 ------- > CPPFLAGS='-I/usr/local/include' > > > Do you have CPPFLAGS set if so this is your bug and not GCC's configure bug. > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21268 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > You are on the CC list for the bug, or are watching someone who is. >
I can confirm this issue. Running : mv /usr/local/include/options.h /usr/local/include/options.h_ before building gcc40 solves the problem...
Created attachment 9529 [details] patch to fix the problem Well, the bug is that if AM_ICONV puts its paths in CPPFLAGS, our include file search path should be placed before $(CPPFLAGS). You may try the attached patch.
I have tried it and successfully bootstrapped the compiler with. It works, thanks.
Subject: Bug 21268 CVSROOT: /cvs/gcc Module name: gcc Changes by: bonzini@gcc.gnu.org 2005-08-29 13:52:38 Modified files: gcc : ChangeLog Makefile.in Log message: 2005-08-18 Paolo Bonzini <bonzini@gnu.org> PR bootstrap/21268 * Makefile.in (ALL_CPPFLAGS): Include $(INCLUDES) at the beginning. Remove $(INCLUDES) from all the rules, if following $(ALL_CPPFLAGS) or $(BUILD_CPPFLAGS). Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9848&r2=2.9849 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&r1=1.1536&r2=1.1537
Subject: Bug 21268 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: bonzini@gcc.gnu.org 2005-08-29 14:04:18 Modified files: gcc : ChangeLog Makefile.in Log message: 2005-08-29 Paolo Bonzini <bonzini@gnu.org> PR bootstrap/21268 * Makefile.in (ALL_CPPFLAGS): Include $(INCLUDES) at the beginning. Remove $(INCLUDES) from all the rules, if following $(ALL_CPPFLAGS) or $(BUILD_CPPFLAGS). Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.399&r2=2.7592.2.400 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1447.2.3&r2=1.1447.2.4
Patch applied.