Major CVS LFS bug - binutils-220.127.116.11
gschafer at zip.com.au
Mon Jan 27 16:34:54 PST 2003
On Tue, Jan 28, 2003 at 12:19:28AM -0000, Matthew Burgess wrote:
> Notified gcc or binutils upstream or both?
All three :-)
(including glibc - glibc's code is the victim here)
> 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 18.104.22.168 release then it
> should be safe for the book to revert to 2.13.2 shouldn't it?
I should think so. Simple to look at the diff.
> 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.
tigers-lfs:~# ld -v
GNU ld version 22.214.171.124.16 20021126
tigers-lfs:~# /home/gws/testing/bin/ld -v
GNU ld version 126.96.36.199
> 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?
Careful. A week hasn't passed yet since HJ's latest release. One of the
criteria I mentioned a while back was to wait a week or so for the dust to
settle (remember HJ releases more closely follow the binutils CVS HEAD).
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev