On Thu, Mar 3, 2011 at 23:38, Paolo Bonzini wrote:
> On 03/03/2011 05:26 PM, Diego Novillo wrote:
>>
>> On Thu, Mar 3, 2011 at 00:27, Paolo Bonzini 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.
