RE: stable binutils, gcc, glibc ...

["Jay Carlson" <nop@nop.com>]

Ralf Baechle writes:

> > d) glibc v2.0.7 from linux-vr project by Jay
> >
> > ftp://ftp.place.org/pub/nop/linuxce/
> > ftp://ftp.place.org/pub/nop/linuxce/rpms/glibc-2.0.7-20.src.rpm
>
> 2.0.7 has resulted in so many bug reports that I consider to
> plain dump any
> related reports in the future.

Hey, don't blame me for the 2.0.6->2.0.7 version bump.  I just grabbed the
biggest version number on oss.sgi.com at the time and made my *trivial*
patches to add softfloat to the build.

Let me say that again: 2.0.7 is NOT MY FAULT.

:-)

Seriously, I think the best thing we can do in this situation is start
assigning our own linux-mips version numbers to combinations of upstream
sources and our patches.  So, we'd have something like:

  glibc 2.0.6 + 05lm patches (whatever) == glibc2.0.6 delta 1.0
  glibc 2.0.6 + 06lm patches (whatever) == glibc2.0.6 delta 1.1

  egcs 1.0.3a + ralf's current patches == egcs 1.0.3a delta 1.0
  egcs 1.0.3a + ralf's patches tomorrow == egcs 1.0.3a delta 2.0

  binutils 2.8.1 + standard patches == binutils 2.8.1 delta 1.0
  binutils 2.10.x on 20001014 == binutils 2.10.x delta 1.0
  binutils 2.10.x on 20001015 == binutils 2.10.x delta 2.1

We need to give *names* to the versions of the software we're testing
against.  I haven't bothered trying a world rebuild against gcc 2.96.x
because telling people it worked wouldn't mean anything.  Other people would
not know that they could reproduce my success by getting the same bits as
me.

What I really want to hear is: "I rebuilt gcc, binutils, the kernel,
modutils, and GNU fileutils using gcc 2.96 delta 7.3, binutils 2.10.x delta
5.2, and glibc 2.1.95 delta 1.0", and then know EXACTLY how to reproduce
that at home.  Just saying "current CVS with patches" doesn't help with
reproducibility.

Jay