This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Quote of the day: "matrix of pain"


On Thu, 12 May 2005, Daniel Kegel wrote:

> Robert P. J. Day wrote:

> >   while we're on the topic, is there any value to reducing the size of
> > that matrix by letting some combinations subsume others?  consider the
> > three contiguous columns:
> >
> > 		gcc-3.3.5
> > 	glibc-{2.1.3/2.2.5/2.3.2}
> > 		binutils-2.15
> > 		linux-2.4.26
> >
> >   so the only difference is in the version of glibc.  note how, as you
> > go from left to right in terms of newer versions of glibc, you have
> > more success.  in fact, the success in builds left to right is
> > monotonically non-decreasing.
> >
> >   this suggests that it's more time-efficient to concentrate on the
> > last of those three combinations at the expense of the first two.
> > IOW, anything glibc-2.1.3 or glibc-2.2.5 can do (in that specific
> > context), glibc-2.3.2 can do *at least* as well.
> >
> >   or, at the very least, perhaps some of the older combinations can be
> > dropped as being, well, *too* old.
>
> Hey, some projects need old stuff.   That's life.
> - Dan

oh, i realize that, but some of the combinations seem a bit ... odd.
it makes sense that one might be doing a build with old stuff, or a
build with newer stuff.  but what about the combination of:

	gcc-4.0.0
	glibc-2.1.3
	binutils-2.15
	linux-2.6.11.3

that seems a bit quirky since glibc is relatively ancient while
everything else is quite modern, if not leading edge.  i also note
that that combination wih any glibc < 2.3.4 fails *everywhere*, but
glibc-2.3.4 suddenly has some successes.  at the very least, one might
think that there's little point in listing the complete failure of
glibc-2.3.3 when the step up to glibc-2.3.4 suddenly generates a whole
bunch of successes.

and, just looking at the very right-hand side of the matrix, the
difference between glibc-2.3.4 and glibc-2.3.5 is zero in terms of
results.  in cases like that, might not the slightly more recent
version of glibc subsume the older version, all other things being
equal?

just thinking out loud.

rday

p.s.  as one thought for making this more manageable, what about
breaking the matrix in two, based simply on the verison of gcc?

	gcc < 4.0.0	(matrix 1)
	gcc >= 4.0.0	(matrix 2)

i get the feeling that the right-hand side of that matrix is in for
some serious expansion in the near future, no?  and, as you can see,
stepping up to gcc-4.0.0 doesn't build nicely on previous results.  it
seems like that's the obvious point to break the matrix in two.

thoughts?  hey, you could call everything gcc < 4.0.0 "legacy". :-)

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]