> [It's not a real scenario of course, but it does have the right flavor
> of the problem I wish to solve.]
> It's the day-to-day development of a fresh port that I want to speed up.
> If I've gone through a run of "make check-gcc" and fixed some random
> bugs, with fixes in any or all of libgloss
Eric writes:
> > So your target audience is "people who use newlib, use the uberbaum
> > build, and who work on multiple gcc trees", right? Seems
> > like such a small audience it's not likely to be widely used,
> > but that's just my impression.
>
> I agree unfortunately. Really if you're
> So your target audience is "people who use newlib, use the uberbaum
> build, and who work on multiple gcc trees", right? Seems
> like such a small audience it's not likely to be widely used,
> but that's just my impression.
I agree unfortunately. Really if you're not wanting to have a single
t
Joe Buck wrote:
On Wed, Jul 06, 2005 at 12:49:52PM -0700, Doug Evans wrote:
Building a cross compiler from scratch "just works" (as in all one
has to do is "configure, make all install") if all of binutils, gcc,
newlib, libgloss, libstdc++, etc. are siblings.
[At least this use to "just work".]
On Wed, Jul 06, 2005 at 12:49:52PM -0700, Doug Evans wrote:
> Building a cross compiler from scratch "just works" (as in all one
> has to do is "configure, make all install") if all of binutils, gcc,
> newlib, libgloss, libstdc++, etc. are siblings.
> [At least this use to "just work".]
>
> The nu
Building a cross compiler from scratch "just works" (as in all one
has to do is "configure, make all install") if all of binutils, gcc,
newlib, libgloss, libstdc++, etc. are siblings.
[At least this use to "just work".]
The number of hoops one has to go through when this isn't the
case can be pain
