Major CVS LFS bug - binutils-

Matthew Burgess ca9mbu at
Mon Jan 27 16:19:28 PST 2003

"Greg Schafer" <gschafer at> wrote in message
news:20030127235022.GA22360 at
> On Mon, Jan 27, 2003 at 04:39:09PM -0700, Gerard Beekmans wrote:
> > On January 27, 2003 04:26 pm, Zack Winkles wrote:
> > > release came out a few days ago, and i know for a
fact that
> >
> > I doubt that'll work with gcc-3.2.1
> >
> > If GCC-3.2.1 can't deal with a version string of how can it
> > deal with a string (containing 5 parts)
> Take a look at the code and weep :-)
> HJ's releases also have a date string which (if available) gets used
> preference to the version string.
> Greg
> PS - I have notified upstream.

Notified gcc or binutils upstream or both?  IMO It's a binutils
versioning bug, I thought all GNU software followed the triplet
convention (can't remember off the top of my head where I thought I'd
read that).  Anyway, if you're correct in thinking that it's only
documentation updates that were done for the release then it
should be safe for the book to revert to 2.13.2 shouldn't it?

Whilst writing this I've seen Gerards confusion come and gone, yet I'm
still a bit bemused.  I'm assuming that HJ Lu's date string is it's
mitigating factor, i.e. it gets checked first, regardless of the version
string.  So, why can't GNU's binutils date string be parsed in the same
fashion?  My MinGW (Minimal GNU for Windows) system here shows a date

$ as --version
GNU assembler 2.13.90 20030104

I don't have access to my linux box at the moment so can't check whether
this was a MinGW specific change, but I wouldn't have thought so.

Oh sod it, I've just retyped this thing 3 times following on from
different replies.  Let's just go with HJ's release hey?  If it'll make
gcc and the chaps on LKML happy then it can't be bad can it?



Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list