Hi Joel,
> I tracked down a bug in building v850-rtems to a place in libgcc/config.host
> where the code setting tmake_file did not append, it overwrote the previous
> value. This caused v850-rtems to throw away the previous setting which
> adding the newlib/sys/rtems/* directories to the include path.
>
> diff --git a/libgcc/config.host b/libgcc/config.host
> index bdc725f..f8f74cc 100644
> --- a/libgcc/config.host
> +++ b/libgcc/config.host
> @@ -1195,7 +1195,7 @@ tilepro*-*-linux*)
> md_unwind_header=tilepro/linux-unwind.h
> ;;
> v850*-*-*)
> - tmake_file="v850/t-v850 t-fdpbit"
> + tmake_file="${tmake_file} v850/t-v850 t-fdpbit"
> ;;
> vax-*-linux*)
> tmake_file="$tmake_file vax/t-linux"
I suppose this happened in the course of my libgcc move patches for gcc
4.7. Unfortunately, almost no one responded to my call for testers in
that timeframe, so it must have gone unnoticed since.
> I see other places in this case statement where tmake_file is reset. Is
> this OK?
> Should be be added to all the time when the pattern is CPU*-*-*? all the
> time?
It's almost impossible to tell in general without a detailed analysis of
each individual case. Unless a specific problem is noticed, I'd leave
it alone for now, especially given how late in the 4.9 cycle we are.
> On a style inconsistency note, I see that some stanzas use $tmake_file
> while
> most use ${tmake_file}. Is there a rule? Personally I like having {} and
> most
> appear to have it.
True, there are many inconsistencies like this, and many more. I still
have this stuff on my agenda for when I hope to resume and finish my
libgcc move work. For the moment, I'd go with what is used in the
vicinity of a change you're going to make.
Hope this helps.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
