On Thu, Mar 3, 2011 at 23:38, Paolo Bonzini <bonz...@gnu.org> wrote: > On 03/03/2011 05:26 PM, Diego Novillo wrote: >> >> On Thu, Mar 3, 2011 at 00:27, Paolo Bonzini<bonz...@gnu.org> wrote: >>> >>> On 03/02/2011 10:00 PM, Ian Lance Taylor wrote: >>>> >>>> That does not sound like the right approach to me. Why not add the new >>>> flags to GCC_FOR_TARGET at top-level? It seems to me that >>>> GCC_FOR_TARGET should mean the same thing at all levels. >>> >>> I agree. Why is it incorrect to use those flags when, say, compiling >>> libgcc? >> >> They would be OK, but what puzzled me is that toplevel Makefile.in and >> gcc/Makefile.in have *different* definitions of GCC_FOR_TARGET. So, >> independently of what I'm trying to do, the definition of >> GCC_FOR_TARGET inside gcc/Makefile.in is always dead: >> >> Makefile.in: >> GCC_FOR_TARGET=$(STAGE_CC_WRAPPER) @GCC_FOR_TARGET@ >> >> gcc/Makefile.in: >> GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./xgcc -B./ >> -B$(build_tooldir)/bin/ -isystem $(build_tooldir)/include -isystem >> $(build_tooldir)/sys-include -L$(objdir)/../ld >> >> So, the variable will be set to different values if you run 'make' >> from toplevel or from gcc/ >> >> Is that by design? > > They should be kept in sync as much as possible. The ability to run 'make' > from gcc/ is a feature, and "make check" needs a definition of > GCC_FOR_TARGET.
Sure, but my question was whether I should prepare a patch to fix the current lack of consistency between the two definitions. Diego.
