This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Q: Estimated date for 2.16 release ?
- From: Daniel Jacobowitz <drow at false dot org>
- To: binutils at sources dot redhat dot com
- Date: Thu, 24 Feb 2005 12:31:32 -0500
- Subject: Re: Q: Estimated date for 2.16 release ?
- References: <OF61577335.B313AA4D-ONC2256F96.004AE546-C2256F96.004B5A37@nsc.com> <20050127140010.GA447@nevyn.them.org> <Pine.BSF.4.58.0501270916170.56553@dair.pair.com> <m3u0p2x5xp.fsf@gossamer.airs.com> <Pine.BSF.4.58.0501271054260.14970@dair.pair.com> <20050127160515.GA5250@nevyn.them.org> <Pine.BSF.4.58.0501271126570.35923@dair.pair.com>
On Sun, Jan 30, 2005 at 09:10:52PM -0500, Hans-Peter Nilsson wrote:
> On Thu, 27 Jan 2005, Daniel Jacobowitz wrote:
> > On Thu, Jan 27, 2005 at 10:56:30AM -0500, Hans-Peter Nilsson wrote:
> > > On Thu, 27 Jan 2005, Ian Lance Taylor wrote:
> > > > Hans-Peter Nilsson <hp@bitrange.com> writes:
> > > > > BTW, was the intl/ directory about to be added to binutils?
> > > > > Maybe that and the fallout should be done before the release.
> > > > > Or maybe better done after branching?
> > > > The binutils releases already have an intl directory, don't they?
> > > > They used to, and it seems to me that they still do.
> > >
> > > Oh right you are, problem misdiagnosed. Still a problem,
> > > though, and one that would be good to fix before the next
> > > release.
> >
> > It's more complicated than you think :-)
>
> Uh, remind me: what did I think? (I made no claim about
> simplicity above. ;-)
>
> FWIW, one workaround is to remove the intl directory from the
> combined sources. Perhaps better than upgrading binutils to
> autoconf 2.59 at this time (which would seem necessary in order
> to sync the intl machinery).
Anyway, it sounds like this is specifically related to combined builds,
and therefore not an issue for 2.16; if you try to combine released
toolchain components rather than HEAD, this is the least of your
problems :-)
> Anyway, I've seen a problem with the stabs linker-warning
> machinery (see libgloss/libnosys/warning.h) and a.out; there's a
> SEGV which valgrind says is an invalid access, after allocated
> memory. Valgrind also changes the behavior and instead of the
> linker warnings, the symbols are undefined. PR and testcase
> later.
I believe that you've fixed this since the above message. Am I
remembering rightly?
--
Daniel Jacobowitz
CodeSourcery, LLC