Building gcc trunk with... ../gcc-4.4-20081026/configure --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with- arch=nocona --with-tune=generic --build=i686-apple-darwin9 --with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/us r/X11R6/lib --with-cloog=/sw --with-ppl=/sw --disable-libjava-multilib has always worked on i686-apple-darwin9 until recently. Now the CPPFLAGS setting of -I/sw/include is being unset at the toplevel Makefile (even though it is set in the Makefile in the libcpp subdirectory). This causes the bootstrap to fail as... gcc -I../../gcc-4.4-20081026/libcpp -I. -I../../gcc-4.4-20081026/libcpp/../include -I../../gcc-4.4-20081026/libcpp/include -g -fkeep-inline-functions -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -I../../gcc-4.4-20081026/libcpp -I. -I../../gcc-4.4-20081026/libcpp/../include -I../../gcc-4.4-20081026/libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../../gcc-4.4-20081026/libcpp/charset.c In file included from ../../gcc-4.4-20081026/libcpp/charset.c:22: ../../gcc-4.4-20081026/libcpp/system.h:255:21: error: libintl.h: No such file or directory make[3]: *** [charset.o] Error 1 make[2]: *** [all-stage1-libcpp] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 If one goes into /sw/src/fink.build/gcc44-4.3.999-20081026/darwin_objdir/libcpp and executes make the compile completes as... gcc -I../../gcc-4.4-20081026/libcpp -I. -I../../gcc-4.4-20081026/libcpp/../include -I../../gcc-4.4-20081026/libcpp/include -I/sw/include -g -fkeep-inline-functions -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -I../../gcc-4.4-20081026/libcpp -I. -I../../gcc-4.4-20081026/libcpp/../include -I../../gcc-4.4-20081026/libcpp/include -I/sw/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../../gcc-4.4-20081026/libcpp/charset.c The missing -I/sw/include set in the line... CPPFLAGS = -I/sw/include ...in the Makefile in /sw/src/fink.build/gcc44-4.3.999-20081026/darwin_objdir/libcpp. However at the toplevel, /sw/src/fink.build/gcc44-4.3.999-20081026/darwin_objdir, has... CPPFLAGS_FOR_BUILD = ... CPPFLAGS = ... CPPFLAGS_FOR_TARGET = I believe this was caused by... ----------------------------------------------------------------------- r141292 | drow | 2008-10-22 09:30:19 -0400 (Wed, 22 Oct 2008) | 21 lines ./ PR gdb/921 PR gdb/1646 PR gdb/2175 PR gdb/2176 * Makefile.def (flags_to_pass): Add CPPFLAGS_FOR_BUILD and CPPFLAGS. * Makefile.tpl (BUILD_EXPORTS): Set CPPFLAGS. (EXTRA_BUILD_FLAGS): Correct typo. Pass CPPFLAGS. (HOST_EXPORTS): Pass CPPFLAGS. (CPPFLAGS_FOR_BUILD, CPPFLAGS, CPPFLAGS_FOR_TARGET): Define. (LDFLAGS_FOR_TARGET): Initialize from configure script. (EXTRA_TARGET_FLAGS): Set CPPFLAGS. * Makefile.in, configure: Regenerated. * configure.ac: Set CPPFLAGS_FOR_TARGET, LDFLAGS_FOR_TARGET, and CPPFLAGS_FOR_BUILD. libiberty/ * Makefile.in (CPPFLAGS): Define. (FLAGS_TO_PASS, COMPILE.c): Add CPPFLAGS. Currently I have to explicitly set CPPFLAGS to build gcc trunk which results in many duplicate instances of -I/sw/include throughout the build.
Created attachment 16554 [details] Toplevel Makefile from 20081016 build on i686-apple-darwin9
Created attachment 16555 [details] libcpp level Makefile from 20081016 build on i686-apple-darwin9
Created attachment 16556 [details] Toplevel Makefile from 20081026 build on i686-apple-darwin9
Created attachment 16557 [details] libcpp level Makefile from 20081026 build on i686-apple-darwin9
Created attachment 16558 [details] toplevel config.log from 20081016
Created attachment 16559 [details] libcpplevel config.log from 20081016
Created attachment 16560 [details] toplevel config.log from 20081026
Created attachment 16561 [details] libcpplevel config.log from 20081026
Created attachment 16562 [details] toplevel config.log from 20081026
Do you have: 2008-10-24 Daniel Jacobowitz <dan@codesourcery.com> * Makefile.tpl (HOST_EXPORTS): Correct CPPFLAGS typo. * Makefile.in: Regenerated. What was previously setting CPPFLAGS? I don't see anything in your command line that would.
I have... 2008-10-24 Daniel Jacobowitz <dan@codesourcery.com> * Makefile.tpl (HOST_EXPORTS): Correct CPPFLAGS typo. * Makefile.in: Regenerated. already. I think the issue is that while both libcpp/configure of 20081016 and 20081026 are properly setting CPPFLAGS in the libcpp/Makefile, after your changes setting of CPPFLAGS now also occurs in the toplevel Makefile and that is being used instead of the setting of CPPFLAGS in libcpp/Makefile. Notice even though the build fails in current gcc trunk, if I go into the libcpp and execute make the problem doesn't occur because CPPFLAGS is defined properly in that Makefile and the toplevel Makefile doesn't get a chance to override it.
I notice that both config.log from the libcpp subdirectory before and after your change have... ac_cv_env_CPPFLAGS_set=set ac_cv_env_CPPFLAGS_value= which is followed by the occurance of... CPPFLAGS='-I/sw/include' but I don't see those ac_cv_env_CPPFLAGS related entries in the config.log from the top level.
Created attachment 16566 [details] diff between toplevel Makefiles before and after drow's changes
Created attachment 16567 [details] diff between libcpp Makefiles before and after drow's changes
Looking at diffs (attached) between the Makefiles in the toplevel and libcpp subdirectory before and after drow's changes, I don't see any significant differences in the libcpp level Makefile. However I suspect the problem with the CPPFLAGS becoming unset after drow's patch is due to the instance of... @@ -343,6 +347,7 @@ GNATMAKE = no CFLAGS = -g -O2 +CPPFLAGS = LDFLAGS = LIBCFLAGS = $(CFLAGS) CXXFLAGS = -g -O2 which comes after... @@ -147,9 +148,10 @@ WINDMC="$(WINDMC_FOR_BUILD)"; export WINDMC; # These variables must be set on the make command line for directories -# built for the build system to override those in BASE_FLAGS_TO_PASSS. +# built for the build system to override those in BASE_FLAGS_TO_PASS. EXTRA_BUILD_FLAGS = \ CFLAGS="$(CFLAGS_FOR_BUILD)" \ + CPPFLAGS="$(CPPFLAGS_FOR_BUILD)" \ LDFLAGS="$(LDFLAGS_FOR_BUILD)" # This is the list of directories to built for the host system. @@ -169,6 +171,7 @@ ADA_CFLAGS="$(ADA_CFLAGS)"; export ADA_CFLAGS; \ CFLAGS="$(CFLAGS)"; export CFLAGS; \ CONFIG_SHELL="$(SHELL)"; export CONFIG_SHELL; \ + CPPFLAGS="$(CPPFLAGS)"; export CPPFLAGS; \ CXX="$(CXX)"; export CXX; \ CXXFLAGS="$(CXXFLAGS)"; export CXXFLAGS; \ AR="$(AR)"; export AR; \ Wouldn't setting CPPFLAGS= to a null string effectively undo the previous exports of CPPFLAGS?
I must admit I am still baffled at why the current gcc trunk code doesn't honor the setting of CPPFLAGS=-I/sw/include in the libcpp level Makefile. Is that Makefile not really used in the stage 1 bootstrap of libcpp? If so, it seems strange to have a configure in libcpp if the generated Makefile is just going to be ignored.
Subject: Re: [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files. On Mon, Oct 27, 2008 at 03:37:27AM -0000, howarth at nitro dot med dot uc dot edu wrote: > already. I think the issue is that while both libcpp/configure of 20081016 and > 20081026 are > properly setting CPPFLAGS in the libcpp/Makefile No they're not. Again, what is setting CPPFLAGS in libcpp? The project is supposed to build correctly with user specified CPPFLAGS, just like CFLAGS. A number of macros in config/ set CPPFLAGS=. My guess is that the path you want is coming from one of those, and they should be setting some other variable. E.g. dnl Sets and AC_SUBSTs the LIB${NAME} and LTLIB${NAME} variables and dnl augments the CPPFLAGS variable.
Do you want to see a different config.log? Should I try to run configure at the top level in a more verbose mode? I'm not sure how to discover where CPPFLAGS is being set for the config.log and Makefile in the libcpp subdirectory.
It won't be logged. Paolo, any comment on the CPPFLAGS problem from comment 17? I want the top level CPPFLAGS passed down, because that's how users can add additional -I arguments. But it seems typical to do CPPFLAGS = foo @CPPFLAGS@ in subdirectories, or put foo in @CPPFLAGS@ in the subdirectory configure script, which loses foo now.
I checked config and I see: - acinclude.m4 CYG_AC_PATH_SIM sets CPPFLAGS, not a problem in this case - tcl.m4 is not a problem like acinclude.m4 is not - gettext.m4 saves CPPFLAGS and restores it - iconv.m4 does the same - lib-link.m4 likes to modify CPPFLAGS (see AC_LIB_APPENDTOVAR) but only in AC_LIB_LINKFLAGS which is not used by the previous two files - lib-prefix.m4 is similarly not a problem The libcppmakefile.diff attachment does not show a change in CPPFLAGS indeed, but it shows that the first file is stage>1, and the second file is stage1. Was this meant? Use "make stage1-start" on both trees" before diffing. Anyway, the desired -I/sw/include flag should be in the two lines of libcpp/Makefile corresponding to INCINTL = @INCINTL@ INCLUDES = -I$(srcdir) -I. -I$(srcdir)/../include @INCINTL@ \ -I$(srcdir)/include rather than in CPPFLAGS, and it should be picked up from $(INCLUDES) *twice*, via ALL_CFLAGS = $(CFLAGS) $(WARN_CFLAGS) $(INCLUDES) $(CPPFLAGS) COMPILE.base = $(CC) $(DEFS) $(INCLUDES) $(CPPFLAGS) $(ALL_CFLAGS) -c I think the bug should be fixed by Index: intl/configure.ac =================================================================== --- intl/configure.ac (revision 141134) +++ intl/configure.ac (working copy) @@ -37,7 +37,6 @@ AC_SUBST(LIBINTL_DEP) AC_SUBST(INCINTL) LIBINTL_DEP= -INCINTL= case $USE_INCLUDED_LIBINTL in yes) LIBINTL=`echo $LIBINTL | sed 's,${top_builddir},&/..,' ` since the invocation of AM_GNU_GETTEXT earlier in intl/configure.ac should have set INCINTL to the correct value for --without-included-gettext. If this is confirmed, the bug has been present since the introduction of the current scheme for gettext configury. r69071 | zack | 2003-07-08 07:55:11 +0200 (Tue, 08 Jul 2003) | 53 lines Jack, can you check the above small patch?
Sorry about the Makefile diffs. The 20081016 build tree had completely bootstrapped whereas the 20081026 build tree had hung on a missing libintl.h header in the stage 1 build of libcpp. I'll try the small patch tonight. I would note that the build failures (without explicitly setting CPPFLAGS) likely started with drow's patch so I guess the bug was latent and he exposed it.
The small patch in comment 20 doesn't help. The build still fails at the same place. I also noticed that with or without the patch I have... CPPFLAGS = -I/sw/include set in the intl/Makefile. Also, I don't even see INCINTL set in either intl/Makefile or toplevel Makefile. It is set to... INCINTL = in libcpp/Makefile.
Just to be clear, I did do... cd intl autoconf -I . -I .. -I ../config after applying the patch.
I still don't understand how the stage1 build of libcpp manages to ignore the CFLAGS setting in the libccp level Makefile. This would suggest that the stage 1 build of libcpp is entirely handled by the toplevel Makefile and the Makefile in libcpp is ignored, no? I only see three instance of CPPFLAGS in the libcpp level Makefile... CPPFLAGS = -I/sw/include ... ALL_CFLAGS = $(CFLAGS) $(WARN_CFLAGS) $(INCLUDES) $(CPPFLAGS) ... COMPILE.base = $(CC) $(DEFS) $(INCLUDES) $(CPPFLAGS) $(ALL_CFLAGS) -c I don't see how, even if CPPFLAGS is unset at the toplevel, that the setting of CPPFLAGS is ignored if the libcpp level Makefile is actually being used in the stage 1 build of libcpp.
Subject: Re: [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files. You do know that A=B in the command line overrides A=C in the makefile right? :-) Does the patch work?
No, I said earlier that the proposed patch doesn't work. Note that INCINTL doesn't even appear in either the toplevel Makefile or the Makefile in intl with your patch. It does appear in the libcpp Makefile but is set to nothing.
Ah, I missed that. But yes, only libcpp/Makefile is supposed to have INCINTL.
Doh, it may be an issue with the fink packaging system. They have a command... NoSetCPPFLAGS: True which I assumed was unsetting CPPFLAGS within fink but it very well may be just setting CPPFLAGS to a null string. I'll remove that and substitute the use of "unsetenv CPPFLAGS" instead. I update the bug report later this evening with the results.
I have verified that the fink build system wasn't in fact setting CPPFLAGS to null or anything else. So this problem is real when CPPFLAGS doesn't exist,
i686-apple-darwin is still a primary target, so P1.
This really happens on all targets.
Since the problem is that libintl.h can't be found, shouldn't we have a toplevel check for libintl and a configure option to set the directory with --with-libintl=%p or such? The INCL_LIBINTL set in the toplevel could then be passed down to the libcpp subdirectory.
> Since the problem is that libintl.h can't be found No, the problem is that INCINTL is not set correctly.
Subject: Bug 37923 Author: drow Date: Fri Nov 14 14:51:38 2008 New Revision: 141859 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141859 Log: PR bootstrap/38014 PR bootstrap/37923 Revert: 2008-10-24 Daniel Jacobowitz <dan@codesourcery.com> * Makefile.tpl (HOST_EXPORTS): Correct CPPFLAGS typo. * Makefile.in: Regenerated. 2008-10-22 Daniel Jacobowitz <dan@codesourcery.com> * Makefile.def (flags_to_pass): Add CPPFLAGS_FOR_BUILD and CPPFLAGS. * Makefile.tpl (BUILD_EXPORTS): Set CPPFLAGS. (EXTRA_BUILD_FLAGS): Correct typo. Pass CPPFLAGS. (HOST_EXPORTS): Pass CPPFLAGS. (CPPFLAGS_FOR_BUILD, CPPFLAGS, CPPFLAGS_FOR_TARGET): Define. (LDFLAGS_FOR_TARGET): Initialize from configure script. (EXTRA_TARGET_FLAGS): Set CPPFLAGS. * Makefile.in, configure: Regenerated. * configure.ac: Set CPPFLAGS_FOR_TARGET, LDFLAGS_FOR_TARGET, and CPPFLAGS_FOR_BUILD. Modified: trunk/ChangeLog trunk/Makefile.def trunk/Makefile.in trunk/Makefile.tpl trunk/configure trunk/configure.ac
Patches reverted. This is really a bug in gmp/mpfr/intl, but no point triggering it.