[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-11-14 Thread drow at gcc dot gnu dot org
--- Comment #34 from drow at gcc dot gnu dot org 2008-11-14 14:53 --- Subject: Bug 37923 Author: drow Date: Fri Nov 14 14:51:38 2008 New Revision: 141859 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141859 Log: PR bootstrap/38014 PR bootstrap/37923

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-11-14 Thread drow at gcc dot gnu dot org
--- Comment #35 from drow at gcc dot gnu dot org 2008-11-14 15:38 --- Patches reverted. This is really a bug in gmp/mpfr/intl, but no point triggering it. -- drow at gcc dot gnu dot org changed: What|Removed |Added

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-31 Thread bonzini at gnu dot org
--- Comment #33 from bonzini at gnu dot org 2008-10-31 06:52 --- Since the problem is that libintl.h can't be found No, the problem is that INCINTL is not set correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-30 Thread rguenth at gcc dot gnu dot org
--- Comment #30 from rguenth at gcc dot gnu dot org 2008-10-30 21:04 --- i686-apple-darwin is still a primary target, so P1. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-30 Thread pinskia at gcc dot gnu dot org
--- Comment #31 from pinskia at gcc dot gnu dot org 2008-10-30 22:18 --- This really happens on all targets. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-30 Thread howarth at nitro dot med dot uc dot edu
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2008-10-30 22:47 --- 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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-28 Thread howarth at nitro dot med dot uc dot edu
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2008-10-28 16:21 --- 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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-28 Thread bonzini at gnu dot org
--- Comment #25 from bonzini at gnu dot org 2008-10-28 16:28 --- 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? --

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-28 Thread howarth at nitro dot med dot uc dot edu
--- Comment #26 from howarth at nitro dot med dot uc dot edu 2008-10-28 16:34 --- 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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-28 Thread bonzini at gnu dot org
--- Comment #27 from bonzini at gnu dot org 2008-10-28 16:39 --- Ah, I missed that. But yes, only libcpp/Makefile is supposed to have INCINTL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-28 Thread howarth at nitro dot med dot uc dot edu
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2008-10-28 16:55 --- 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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-28 Thread howarth at nitro dot med dot uc dot edu
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2008-10-28 23:37 --- 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, --

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-27 Thread howarth at nitro dot med dot uc dot edu
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2008-10-27 13:34 --- Created an attachment (id=16566) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16566action=view) diff between toplevel Makefiles before and after drow's changes --

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-27 Thread howarth at nitro dot med dot uc dot edu
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2008-10-27 13:35 --- Created an attachment (id=16567) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16567action=view) diff between libcpp Makefiles before and after drow's changes --

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-27 Thread howarth at nitro dot med dot uc dot edu
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2008-10-27 13:39 --- 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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-27 Thread howarth at nitro dot med dot uc dot edu
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2008-10-27 13:44 --- 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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-27 Thread drow at gcc dot gnu dot org
--- Comment #17 from drow at gcc dot gnu dot org 2008-10-27 13:55 --- Subject: Re: [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files. On Mon, Oct 27, 2008 at 03:37:27AM -, howarth at nitro dot med dot uc dot edu wrote: already. I think the issue is

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-27 Thread howarth at nitro dot med dot uc dot edu
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2008-10-27 14:03 --- 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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-27 Thread drow at gcc dot gnu dot org
--- Comment #19 from drow at gcc dot gnu dot org 2008-10-27 14:13 --- 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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-27 Thread bonzini at gnu dot org
--- Comment #20 from bonzini at gnu dot org 2008-10-27 14:49 --- 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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-27 Thread howarth at nitro dot med dot uc dot edu
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2008-10-27 15:04 --- 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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-27 Thread howarth at nitro dot med dot uc dot edu
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2008-10-27 23:32 --- 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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-27 Thread howarth at nitro dot med dot uc dot edu
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2008-10-27 23:53 --- Just to be clear, I did do... cd intl autoconf -I . -I .. -I ../config after applying the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-26 Thread pinskia at gcc dot gnu dot org
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|CPPFLAGS now unset for stage|[4.4

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-26 Thread drow at gcc dot gnu dot org
--- Comment #10 from drow at gcc dot gnu dot org 2008-10-27 02:45 --- Do you have: 2008-10-24 Daniel Jacobowitz [EMAIL PROTECTED] * Makefile.tpl (HOST_EXPORTS): Correct CPPFLAGS typo. * Makefile.in: Regenerated. What was previously setting CPPFLAGS? I don't see

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-26 Thread howarth at nitro dot med dot uc dot edu
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2008-10-27 03:37 --- I have... 2008-10-24 Daniel Jacobowitz [EMAIL PROTECTED] * Makefile.tpl (HOST_EXPORTS): Correct CPPFLAGS typo. * Makefile.in: Regenerated. already. I think the issue is that while

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

2008-10-26 Thread howarth at nitro dot med dot uc dot edu
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2008-10-27 03:45 --- 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...