Next release

Next release

[Daniel Jacobowitz]

It's that time again - about a year since the last release of
binutils.

Are there any issues that you'd like addressed before any official
release of the current HEAD?  If so, please let me know.  Otherwise I
plan to make the branch in the next two weeks, and release
approximately a month later.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Next release

[NightStrike]

On 6/27/08, Daniel Jacobowitz <drow@false.org> wrote:
> It's that time again - about a year since the last release of
> binutils.
>
> Are there any issues that you'd like addressed before any official
> release of the current HEAD?  If so, please let me know.  Otherwise I
> plan to make the branch in the next two weeks, and release
> approximately a month later.

There are still a couple failures for the testsuite for
x86_64-pc-mingw32.  For instance, objcopy doesn't work.  Assistance on
that would be very helpful :)

Re: Next release

[Tristan Gingold]

Daniel,

last year I submitted a patch to fix the flags of .sdata2 sections on  
vxworks/ppc:
(http://sourceware.org/ml/binutils/2007-10/msg00314.html)
This patch was approved by Alan (http://sourceware.org/ml/binutils/ 
2007-10/msg00317.html), but
you said (http://sourceware.org/ml/binutils/2007-10/msg00318.html) CS  
has a better patches set to fix
this issue (and certainly others).  At this time, CS never merged or  
submitted this patch.

How to proceed ?  Is CS ready to submit its patch or should I commit  
this one ?

Thanks,
Tristan.

On Jun 27, 2008, at 4:09 PM, Daniel Jacobowitz wrote:

> It's that time again - about a year since the last release of
> binutils.
>
> Are there any issues that you'd like addressed before any official
> release of the current HEAD?  If so, please let me know.  Otherwise I
> plan to make the branch in the next two weeks, and release
> approximately a month later.
>
> -- 
> Daniel Jacobowitz
> CodeSourcery
>

Re: Next release

[Aaron W. LaFramboise]

Daniel Jacobowitz wrote:

> Are there any issues that you'd like addressed before any official
> release of the current HEAD?

As part of my GSoC work for GCC, I'd like to get two relatively small 
changes into binutils before the release: PECOFF TLS init support and 
.eh_frame support for PECOFF.  These are needed to support various 
Windows improvements targetted at GCC 4.4: 
<http://gcc.gnu.org/wiki/WindowsGCCImprovementsGSoC2008>.  These changes 
are specific to i386-pe.

Conservatively, I think both of these changes will be ready by July 
15th.  If that is too late, would it be possible to commit these to the 
branch?  I'd really like to see these features in a binutils that comes 
out before GCC 4.4 does.

Re: Next release

[Daniel Jacobowitz]

On Fri, Jun 27, 2008 at 10:09:31AM -0400, Daniel Jacobowitz wrote:
> It's that time again - about a year since the last release of
> binutils.
> 
> Are there any issues that you'd like addressed before any official
> release of the current HEAD?  If so, please let me know.  Otherwise I
> plan to make the branch in the next two weeks, and release
> approximately a month later.

It is very clear, for anyone who'd been wondering, that I don't have
time to do this any more.

Is there anyone else interested in making binutils releases?  It's not
that big a time commitment and I started doing it before I knew much
about binutils; you just have to be able to make a certain amount of
time and know who to ask for help.  If anyone wants the job, I'll hand
over my notes with glee.

Otherwise, I will try to get a 2.19 release out - but the omens are
looking poor for a branch before October.

And, Tristan, I really haven't forgotten about your question!

-- 
Daniel Jacobowitz
CodeSourcery

Re: Next release

[Tristan Gingold]

I am volunteer to make binutils releases unless someone else is.

Not sure I am the best one to take this job as I don't have much
experience about making releases and about binutils.

But we (=AdaCore) rely on binutils for many targets, we have already
made a few contributions.  We also think that releasing periodically
is important for a project (quality, testing and visibility).

Tristan.

On Aug 12, 2008, at 7:59 PM, Daniel Jacobowitz wrote:

> On Fri, Jun 27, 2008 at 10:09:31AM -0400, Daniel Jacobowitz wrote:
>> It's that time again - about a year since the last release of
>> binutils.
>>
>> Are there any issues that you'd like addressed before any official
>> release of the current HEAD?  If so, please let me know.  Otherwise I
>> plan to make the branch in the next two weeks, and release
>> approximately a month later.
>
> It is very clear, for anyone who'd been wondering, that I don't have
> time to do this any more.
>
> Is there anyone else interested in making binutils releases?  It's not
> that big a time commitment and I started doing it before I knew much
> about binutils; you just have to be able to make a certain amount of
> time and know who to ask for help.  If anyone wants the job, I'll hand
> over my notes with glee.
>
> Otherwise, I will try to get a 2.19 release out - but the omens are
> looking poor for a branch before October.
>
> And, Tristan, I really haven't forgotten about your question!
>
> -- 
> Daniel Jacobowitz
> CodeSourcery
>

RE: Next release

[Weddington, Eric]

 

> -----Original Message-----
> From: Tristan Gingold [mailto:gingold@adacore.com] 
> Sent: Thursday, August 14, 2008 2:44 AM
> To: binutils@sourceware.org
> Cc: Daniel Jacobowitz
> Subject: Re: Next release
> 
> We also think that releasing periodically
> is important for a project (quality, testing and visibility).
> 

Agreed.

Perhaps I'm opening up a can of worms here, but whatever happened to the idea of integrating binutils with gcc, into the same project? Or is that such anathema to anything *nix?

Eric Weddington

Re: Next release

[David Daney]

Weddington, Eric wrote:
>  
> 
>> -----Original Message-----
>> From: Tristan Gingold [mailto:gingold@adacore.com] 
>> Sent: Thursday, August 14, 2008 2:44 AM
>> To: binutils@sourceware.org
>> Cc: Daniel Jacobowitz
>> Subject: Re: Next release
>>
>> We also think that releasing periodically
>> is important for a project (quality, testing and visibility).
>>
> 
> Agreed.
> 
> Perhaps I'm opening up a can of worms here, but whatever happened to the idea of integrating binutils with gcc, into the same project? Or is that such anathema to anything *nix?
> 

The code also intersects gdb, so you could follow the argument to its conclusion and integrate it as well.

My $0.02: Although possible, it would make the release process too cumbersome.  Bugs in any one component would block the release of the entire bundle.  Letting the individual projects progress somewhat independently as they do now allows for more and better releases of all of them.

David Daney

Re: Next release

[David Miller]

From: David Daney <ddaney@avtrex.com>
Date: Fri, 15 Aug 2008 09:19:29 -0700

> My $0.02: Although possible, it would make the release process too
> cumbersome.  Bugs in any one component would block the release of
> the entire bundle.  Letting the individual projects progress
> somewhat independently as they do now allows for more and better
> releases of all of them.

The corollary could also be argued, in that if the trees were
integrated then developers would need to be more mindful about
not adding new regressions in related components.

Re: Next release

[NightStrike]

On 8/15/08, David Miller <davem@davemloft.net> wrote:
> From: David Daney <ddaney@avtrex.com>
> Date: Fri, 15 Aug 2008 09:19:29 -0700
>
> > My $0.02: Although possible, it would make the release process too
> > cumbersome.  Bugs in any one component would block the release of
> > the entire bundle.  Letting the individual projects progress
> > somewhat independently as they do now allows for more and better
> > releases of all of them.
>
> The corollary could also be argued, in that if the trees were
> integrated then developers would need to be more mindful about
> not adding new regressions in related components.
>

Merging them also makes figuring out what version works with what a
heck of a lot easier.

Re: Next release

[Brian Dessent]

David Daney wrote:

> My $0.02: Although possible, it would make the release process too cumbersome.  Bugs in any one component would block the release of the entire bundle.  Letting the individual projects progress somewhat independently as they do now allows for more and better releases of all of them.

Not to mention that it would be rather awkward for the targets that
binutils supports that gcc doesn't (random example, i960), or the
targets that gcc supports that binutils doesn't, like Mach-o/Darwin. 
You'd be forcing those users to download a great deal of code that they
don't need and can't even use.

As I see it they are separate projects and superficially combining them
doesn't really seem like it would accomplish much, especially since the
Cygnus combined tree option has always existed for those that do want to
bootstrap an entire toolchain at once.

If anything it would remove freedoms that exist now, like the ability to
upgrade the assembler or linker to pick up bug fixes without having to
also upgrade to a whole new compiler version at the same time.  (To be
fair, I suppose some people would also say that this need to manually
choose a coupling that is compatible is a liability rather than an
asset.)  You could always disable those parts of the tree you don't want
to build, but I tend to think that if the combined tree becomes the
default then the ability to selectively build invidual pieces would just
bitrot from lack of testing exposure.  And anyway you lose this entirely
if you go the extra step of actually integrating the assembler into the
compiler instead of continuing the separate process pipeline model,
which I think is what the OP was suggesting.

Brian

RE: Next release

[Weddington, Eric]

 

> -----Original Message-----
> From: Brian Dessent [mailto:brian@dessent.net] 
> Sent: Friday, August 15, 2008 3:44 PM
> To: David Daney
> Cc: Weddington, Eric; Tristan Gingold; 
> binutils@sourceware.org; Daniel Jacobowitz
> Subject: Re: Next release
> 
 
> Not to mention that it would be rather awkward for the targets that
> binutils supports that gcc doesn't (random example, i960), or the
> targets that gcc supports that binutils doesn't, like Mach-o/Darwin. 

That always seemed like anomalies to me. What good is it to have support for a target in binutils, but not in gcc, and vice versa.
 
> As I see it they are separate projects and superficially 
> combining them
> doesn't really seem like it would accomplish much, especially 

I was intimating that binutils would, perhaps, benefit from being tied to gcc's release schedule one two fronts: one, it would ensure that it gets released in a timely manner on a regular schedule, as it seems there are more volunteers doing the releasing; two, it could potentially help with compatibility issues, i.e. one wouldn't have to say "use gcc version >= x with binutils release >= y".

> If anything it would remove freedoms that exist now, like the 
> ability to
> upgrade the assembler or linker to pick up bug fixes without having to
> also upgrade to a whole new compiler version at the same time.  

And it could be argued that that freedom is of marginal usefulness, at best. Is binutils *that* much buggier than gcc, that it is *so* incredibly useful to decouple the two to upgrade the assembler and linker with bug fixes, separate from gcc? At this point, gcc releases more often than binutils... I've seen more frequent gdb releases than binutils.

> (To be
> fair, I suppose some people would also say that this need to manually
> choose a coupling that is compatible is a liability rather than an
> asset.)

Agreed.

> And anyway you lose 
> this entirely
> if you go the extra step of actually integrating the 
> assembler into the
> compiler instead of continuing the separate process pipeline model,
> which I think is what the OP was suggesting.

No, I was not trying to suggest such a huge change in behavior. The separate process pipeline model is fine with me.

I was merely curious as to the reasons for such a continued *project* separation (purposely ignoring "historical" reasons). It just seems bizarre to me that binutils and gcc enjoy such a good coupling, many of the same people work on both projects, yet gcc has 4 release managers, but Daniel doesn't have time to do a binutils release and is looking for volunteers...

Re: Next release

[Brian Dessent]

"Weddington, Eric" wrote:

> That always seemed like anomalies to me. What good is it to have support for a target in binutils, but not in gcc, and vice versa.

Why should users of operating systems like OS X, Solaris 10, HP-UX, AIX,
etc. be denied the ability to use gcc just because the GNU assembler or
GNU linker hasn't been ported to those proprietary systems (or lack
certain features only present in the vendor tools)?  If using gcc also
required a FSF port of the assembler and linker then a whole lot of
users would be out of luck.  This is a valuable feature of the "only a
compiler" design of gcc.

> And it could be argued that that freedom is of marginal usefulness, at best. Is binutils *that* much buggier than gcc, that it is *so* incredibly useful to decouple the two to upgrade the assembler and linker with bug fixes, separate from gcc? At this point, gcc releases more often than binutils... I've seen more frequent gdb releases than binutils.

My point wasn't that one is more buggy than the other.  It's that
changing from gcc X.Y to X.Z can involve a nontrivial amount of
user-visible changes, particularly with regards to strictness and
semantics.  The newest gcc versions are fierce and merciless to code
that's not 100% language-lawyerly ISO correct where older versions let
it slip.  Code has to be ported and tested; unintended undefined
behavior has to be hunted down and rewritten or compile options
adjusted; it's far from a drop-in replacement.  On the other hand, the
assembler and linker have much less room for variance and should ideally
have no detectable effect on language strictness or semantics.  Thus
being able to pick up bugfixes and performance enhancements in the
assembler and linker (and miscellaneous related tools like readelf,
strip, objdump, etc) without also having to also evaluate a whole bunch
of potentially major compiler changes is a significant win, IMHO.

Brian

RE: Next release

[Weddington, Eric]

 

> I was intimating that binutils would, perhaps, benefit from 
> being tied to gcc's release schedule one two fronts: one, it 
---------------------------------------^
"on two fronts:"

Re: Next release

[Daniel Jacobowitz]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

On Thu, Aug 14, 2008 at 10:43:46AM +0200, Tristan Gingold wrote:
> I am volunteer to make binutils releases unless someone else is.

Great!

I've attached my notes on the release process.  I'm sure I forgot some
things; ask me about anything that's unclear.

-- 
Daniel Jacobowitz
CodeSourcery

[-- Attachment #2: checklist.txt --]
[-- Type: text/plain, Size: 4531 bytes --]

Required access
===============

- sourceware.org.  You will need a shell account, not just access to
cvs.  If you do not have shell access, then ask overseers@sourceware.org.
You will also need to be in group binutils to access the web pages.

- savannah.gnu.org.  The gnu.org copy of the web pages are hosted here;
you'll need to be added to the binutils project.  See
http://savannah.gnu.org/projects/binutils.  Create a savannah account and
then the listed project admin can add you.

- ftp-upload.gnu.org.  The official ftp.gnu.org tarballs are uploaded
through fencepost.  You'll need a savannah account first; then see
http://www.gnu.org/prep/maintain/maintain.html#Automated-Upload-Registration.
You may want to ask one of the current maintainers of binutils to
mail ftp-upload@gnu.org on your behalf, to avoid confusion.

To create a release branch
==========================

Add markers for the upcoming release to gas, ld, and binutils NEWS files.

Tag the branchpoint using rtag.

	cvs rtag binutils-2_16-branchpoint binutils

Create the release branch using rtag.

	cvs rtag -b -r binutils-2_16-branchpoint binutils-2_16-branch binutils

Update bfd/configure and bfd/configure.in on HEAD to indicate snapshot of
the following release.

Rename the current HEAD version entry in Bugzilla, and create a new
one.  E.g. rename "2.16 (HEAD)" to 2.16, and create "2.17 (HEAD)".  Go
to "Edit products" from the bottom toolbar, click on "binutils", then
on "Edit versions".  If you don't have permissions to do this,
either ask Daniel Berlin to fix your account or ask Daniel Jacobowitz
to do it.

Regenerate various files on both branch and HEAD by configuring (in-srcdir -
is this necessary?) with --enable-maintainer-mode.  No need to check in
changes to the autoconf/automake/etc files, but be sure the .pot files are
up to date.

Create an initial prerelease and send it to the Translation Project.
  http://translationproject.org/html/maintainers.html
Sending mail for one of the POT files is sufficient.

To create a prerelease
======================

Bump version in bfd/configure.in and bfd/configure on the branch.

Build a snapshot tarball by "make -f src-release binutils.tar.bz2".

Sanity check the release on i686-pc-linux-gnu by building and running the
testsuite.  Make the source directory read-only before building.  Also
test "make install".

Check in generated files on the release branch, by adding the files
left in srcdir by src-release to CVS.  Make sure to use "cvsu -I" or
"cvs -I !" to include the .gmo files, which are listed in cvsignore.
But for a current problem, also see:
  http://lists.gnu.org/archive/html/bug-binutils/2008-06/msg00049.html

Upload the snapshot to sourceware.org, ~ftp/pub/binutils/snapshots/,
owned by group binutils.

Send mail to binutils@sourceware.org announcing the snapshot.

To create a release
===================

Bump version in bfd/configure.in and bfd/configure on the branch.  Also
set RELEASE in bfd/Makefile.am and bfd/Makefile.in.

Build a release tarball by "make -f src-release binutils.tar.bz2".

Sanity check the release on i686-pc-linux-gnu by building and running the
testsuite.  Make the source directory read-only before building.  Also
test "make install".

Check in updated generated files on the branch if necessary.  As with
prereleases, make sure to include the .gmo files.

Tag the branch.

	cvs tag binutils-2_16

Optionally, generate diffs.  If they're unreasonably large, don't bother.

Generate a .tar.gz file from the .tar.bz2 file.

Upload the release to sourceware.org, ~ftp/pub/binutils/releases/,
owned by group binutils.

Upload the release to fencepost.gnu.org.  Directions can be found in a
current version of maintain.texi.

Create a new documentation folder on the sourceware.org web pages.
Update the sourceware.org site to point to the new documentation and
mention the new version.  New documentation is created with "makeinfo
--html".  The html target in the Makefiles works in some directories but not
others.

Update the "docs" symlink in /sourceware/www/sourceware/htdocs/binutils.

Update the sourceware.org binutils web page to refer to the new version,
documentation, and NEWS files.

Update the mirror of the web page on www.gnu.org, via savannah.

Unset RELEASE on the branch.  Bump the version by adding a trailing
.0, so that the date suffix keeps the version lower than the trunk
version.

Send mail to binutils@sourceware.org announcing the release.  Sign it
and include the checksums.  Also CC info-gnu@gnu.org.

Re: Next release

[Tristan Gingold]

On Sep 4, 2008, at 2:02 PM, Daniel Jacobowitz wrote:
>
> I've attached my notes on the release process.  I'm sure I forgot some
> things; ask me about anything that's unclear.


Thank you again for these notes.

One question about --enable-maintainer-mode:
according to src/README-maintainer-mode,

Note that if you configure with --enable-maintainer-mode, you will need
special versions of automake, autoconf, libtool and gettext. You will
find the sources for these in ftp://sources.redhat.com/pub/binutils.

Is it still true ?  The tools on the ftp site date back from 2000.   
Looks quiet old.

Tristan.

Re: Next release

[Daniel Jacobowitz]

On Mon, Sep 08, 2008 at 11:38:19AM +0200, Tristan Gingold wrote:
> Thank you again for these notes.
>
> One question about --enable-maintainer-mode:
> according to src/README-maintainer-mode,
>
> Note that if you configure with --enable-maintainer-mode, you will need
> special versions of automake, autoconf, libtool and gettext. You will
> find the sources for these in ftp://sources.redhat.com/pub/binutils.
>
> Is it still true ?  The tools on the ftp site date back from 2000.  Looks 
> quiet old.

It's only partly true.

You do need particular versions of the tools, because you should use
the ones that match the source tree.  But they're not the ones from
that directory any more; for instance it is autoconf 2.59 now.

But I don't bother putting them in my PATH for this step; my system
tools are good enough to build, and I only check in changes to the
.pot files; I revert any regenerated configury bits (since we keep
them up to date in the repository with every commit).

-- 
Daniel Jacobowitz
CodeSourcery

Re: Next release

[Joern Rennecke]

I've been trying to test a patch that amends / replaces
Renesas references with SuperH references where appropriate,
but the testsuite keeps finding problems that are not related
to my patch.  In binutils, I found that the readelf -wi test
failed - see
http://sources.redhat.com/ml/binutils/2003-04/msg00415.html
http://sources.redhat.com/ml/binutils/2003-04/msg00416.html
http://sources.redhat.com/ml/binutils/2003-04/msg00420.html

For ld, there are three FAILures and one ERROR which is
not a failurei (???).  One of the FAILs has been introduced
in the last year.

-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: Next release

[Daniel Jacobowitz]

On Wed, Apr 23, 2003 at 05:17:05PM +0100, Joern Rennecke wrote:
> I've been trying to test a patch that amends / replaces
> Renesas references with SuperH references where appropriate,
> but the testsuite keeps finding problems that are not related
> to my patch.  In binutils, I found that the readelf -wi test
> failed - see
> http://sources.redhat.com/ml/binutils/2003-04/msg00415.html
> http://sources.redhat.com/ml/binutils/2003-04/msg00416.html
> http://sources.redhat.com/ml/binutils/2003-04/msg00420.html
> 
> For ld, there are three FAILures and one ERROR which is
> not a failurei (???).  One of the FAILs has been introduced
> in the last year.

You didn't say in those messages what target you were testing on, IIRC. 
Is it sh-elf?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Next release

[Joern Rennecke]

Daniel Jacobowitz wrote:
> You didn't say in those messages what target you were testing on, IIRC.
> Is it sh-elf?

Yes, it is.
	
-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: Next release

[Nick Clifton]

Hi Joern,

> I've been trying to test a patch that amends / replaces
> Renesas references with SuperH references where appropriate,
> but the testsuite keeps finding problems that are not related
> to my patch.

If the failures are not related to your patch - ie there are no
regressions - then it need not hold up your submission.


> In binutils, I found that the readelf -wi test failed - see

This should now be resolved.  Please let me know if it is not.

> For ld, there are three FAILures and one ERROR which is
> not a failurei (???).  One of the FAILs has been introduced
> in the last year.

Can you provide more details please ?  Also, since you are an SH
maintainer perhaps you would like to investigate them and find out if
they are really SH related or generic.

Cheers
        Nick

Re: Next release

[Nick Clifton]

Hi Daniel,

> Binutils version 2.13.2.1 was released three months ago today.  That
> tells me that we're about do for 2.14.

Timed nicely to coincide with gcc 3.3.  Excellent.

> I know there are a couple major instabilities and unsettled issues
> right now; if you know any in particular that you would want
> resolved before a release please tell me.

One thing - I would prefer to wait until the status of the Xtensa port
contribution is settled.  We may have to pull the sources from the
repository if we cannot resolve the auto-generated files issue.

Cheers
        Nick

Re: Next release

[Dimitrie O. Paun]

On April 2, 2003 07:58 am, Nick Clifton wrote:
> > I know there are a couple major instabilities and unsettled issues
> > right now; if you know any in particular that you would want
> > resolved before a release please tell me.
>
> One thing - I would prefer to wait until the status of the Xtensa port
> contribution is settled.  We may have to pull the sources from the
> repository if we cannot resolve the auto-generated files issue.

And please don't forget the windres patches (for -J and -U), those
are needed for bug #134113 in Mozilla:
    http://bugzilla.mozilla.org/show_bug.cgi?id=134113
The -J one is pending my copyright assignment at the FSF. Unless there
are some problems with that one, it should be resolved in a matter of 
days as I suspect the FSF received my signed form by now.

-- 
Dimi.

Next release

[Daniel Jacobowitz]

Binutils version 2.13.2.1 was released three months ago today.  That tells
me that we're about do for 2.14.  I know there are a couple major
instabilities and unsettled issues right now; if you know any in particular
that you would want resolved before a release please tell me.  Similarly if
you have any interesting features you're planning to contribute soon, etc. 
When I've got a handle on how much needs to settle down before we can
branch, I'll post a schedule.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Next release

[Stephane Carrez]

Hi Daniel,

Daniel Jacobowitz wrote:
> Binutils version 2.13.2.1 was released three months ago today.  That tells
> me that we're about do for 2.14.  I know there are a couple major
> instabilities and unsettled issues right now; if you know any in particular
> that you would want resolved before a release please tell me.  Similarly if
> you have any interesting features you're planning to contribute soon, etc. 
> When I've got a handle on how much needs to settle down before we can
> branch, I'll post a schedule.
> 

I have a (big) pending work on HC11/HC12 that I made on 2.12.1 and want to
report on 2.14.  It factorizes the bfd HC11/HC12 code and implements
HC11/HC12 trampoline generation during a final link.  It is fully functional
on 2.12.1 but I must convert a number of things due to the bfd changes
(symbols is what comes to my mind).

Depending on your schedule I'll try to do this during the next 2 weeks
but if you give us a little bit more time I'll definately appreciate.

	Stephane

-- 
         Home                           Office
E-mail: stcarrez@nerim.fr              Stephane.Carrez@solsoft.fr
WWW:    http://stcarrez.nerim.net      http://www.solsoft.com
         Free the Software!             Simplifying Security Policy Management

Re: Next release

[Daniel Jacobowitz]

On Tue, Apr 01, 2003 at 09:35:20PM +0200, Stephane Carrez wrote:
> Hi Daniel,
> 
> Daniel Jacobowitz wrote:
> >Binutils version 2.13.2.1 was released three months ago today.  That tells
> >me that we're about do for 2.14.  I know there are a couple major
> >instabilities and unsettled issues right now; if you know any in particular
> >that you would want resolved before a release please tell me.  Similarly if
> >you have any interesting features you're planning to contribute soon, etc. 
> >When I've got a handle on how much needs to settle down before we can
> >branch, I'll post a schedule.
> >
> 
> I have a (big) pending work on HC11/HC12 that I made on 2.12.1 and want to
> report on 2.14.  It factorizes the bfd HC11/HC12 code and implements
> HC11/HC12 trampoline generation during a final link.  It is fully functional
> on 2.12.1 but I must convert a number of things due to the bfd changes
> (symbols is what comes to my mind).
> 
> Depending on your schedule I'll try to do this during the next 2 weeks
> but if you give us a little bit more time I'll definately appreciate.

Hi Stephane,

Any progress?  Given the current state of the tree, I'm considering a
release branch in the next week or so.  I've still got my eye on the
pending -J patch for windres.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Next release

[Dimitrie O. Paun]

On Thu, 17 Apr 2003, Daniel Jacobowitz wrote:

> Any progress?  Given the current state of the tree, I'm considering a
> release branch in the next week or so.  I've still got my eye on the
> pending -J patch for windres.

Yes, please do. I don't know what's going on with it, it's out of my
hands -- they copyright assignment is in, the code wa submitted.
I also have another little patch to support -fo for compatibility with
rc, so we can eliminate uglu ifdefs in Makefiles (for Mozilla in
particular, but many other projects can benefit from command line
compatibility between windres/wrc/rc).

-- 
Dimi.

Re: Next release

[Richard Henderson]

On Thu, Apr 17, 2003 at 04:29:18PM -0400, Daniel Jacobowitz wrote:
> Any progress?  Given the current state of the tree, I'm considering a
> release branch in the next week or so.

Note that I've got a pending ia64 ld bug that's going to require
splitting the relax_section hook into several pieces.  If I don't
get to this soon enough we'll need to disable relaxation of ldxmov
on the release branch.


r~

Re: Next release

[H. J. Lu]

On Thu, Apr 17, 2003 at 03:54:40PM -0700, Richard Henderson wrote:
> On Thu, Apr 17, 2003 at 04:29:18PM -0400, Daniel Jacobowitz wrote:
> > Any progress?  Given the current state of the tree, I'm considering a
> > release branch in the next week or so.
> 
> Note that I've got a pending ia64 ld bug that's going to require
> splitting the relax_section hook into several pieces.  If I don't
> get to this soon enough we'll need to disable relaxation of ldxmov
> on the release branch.
> 

I disabled ldxmov in bfd. I still got the same error.

H.J.

Re: Next release

[Stephane Carrez]

Hi Daniel,

Daniel Jacobowitz wrote:
> On Tue, Apr 01, 2003 at 09:35:20PM +0200, Stephane Carrez wrote:
> 
>>Hi Daniel,
>>
>>Daniel Jacobowitz wrote:
>>
>>>Binutils version 2.13.2.1 was released three months ago today.  That tells
>>>me that we're about do for 2.14.  I know there are a couple major
>>>instabilities and unsettled issues right now; if you know any in particular
>>>that you would want resolved before a release please tell me.  Similarly if
>>>you have any interesting features you're planning to contribute soon, etc. 
>>>When I've got a handle on how much needs to settle down before we can
>>>branch, I'll post a schedule.
>>>
>>
>>I have a (big) pending work on HC11/HC12 that I made on 2.12.1 and want to
>>report on 2.14.  It factorizes the bfd HC11/HC12 code and implements
>>HC11/HC12 trampoline generation during a final link.  It is fully functional
>>on 2.12.1 but I must convert a number of things due to the bfd changes
>>(symbols is what comes to my mind).
>>
>>Depending on your schedule I'll try to do this during the next 2 weeks
>>but if you give us a little bit more time I'll definately appreciate.
> 
> 
> Hi Stephane,
> 
> Any progress?  Given the current state of the tree, I'm considering a
> release branch in the next week or so.  I've still got my eye on the
> pending -J patch for windres.
> 
Yes.  I have the following patchs in my queue:

  - one for ld to support trampoline generation on HC11/HC12
    (new emultempl/m68hc1xelf.em file); I'll commit it today.

  - one for bfd to merge various bfd/elf HC11/HC12 functions from
    elf32-m68hc11.c/elf32-m68hc12.c in a single file 'elf32-m68hc1x.c'
    I'll send the patch today and commit it on monday if it's ok

  - one for bfd to cleanup elf32-m68hc11.c/elf32-m68hc12.c to use the
    shared file (also updates Makefile.am, configure.in to compile the
    new file);  I'll send the patch today and commit on monday.

  - one for ld to use the new emultempl HC11/HC12 file together
    with the bfd part.  Send today, commit on monday.

So, if everything goes well I should have everything by this monday.

	Stephane

Re: next release

[Mark E.]

> Does anybody know what the status is on Linux/MIPS?  I'd also be grateful if
> someone could test the current code on Solaris and DJGPP.

I've been using the current cvs with DJGPP without incident. Problems 
discovered with COFF debug info and finding stabs line info have been fixed. 
Dwarf2 info works with addr2line, objdump, etc. No complaints here.

Mark
 

Re: next release

[Philip Blundell]

On 27 Dec, I wrote:

>So, it's that time again when thoughts inevitably turn to a new version of 
>GNU binutils.  I'd like to aim for a release at the start of March, with a 
>freeze at the end of January.  

I'm not aware of any outstanding problems that should delay the release now.  
Unless anything turns up, I plan to make the branch in a week's time, on Jan 
20 - this will also be the cut-off date for new features.

Does anybody know what the status is on Linux/MIPS?  I'd also be grateful if 
someone could test the current code on Solaris and DJGPP.

p.

Re: next release

[Mark E.]

> I'd also be grateful if 
> someone could test the current code on Solaris and DJGPP.
> 

And test again after:
http://sources.redhat.com/ml/binutils/2001-01/msg00083.html
http://sources.redhat.com/ml/binutils/2001-01/msg00092.html

have been 'approved and applied'.

I'd also like to find an acceptable way to get rid of the random garbage that 
shows up between the section header and the first section in an executable 
(that's there because the OS doesn't blank out parts of a file created 
because of seeks).

Mark

Re: next release

[Maciej W. Rozycki]

On Sat, 13 Jan 2001, Philip Blundell wrote:

> I'm not aware of any outstanding problems that should delay the release now.  
> Unless anything turns up, I plan to make the branch in a week's time, on Jan 
> 20 - this will also be the cut-off date for new features.
> 
> Does anybody know what the status is on Linux/MIPS?  I'd also be grateful if 
> someone could test the current code on Solaris and DJGPP.

 I've sent the patches I was able to integrate so far.  All of them were
previously sent to the list and didn't get applied either with no comment
whatsoever or they just got lost after a positive reply (in the Ian's
days). 

 I have a few other MIPS or Linux/MIPS patches pending I am currently
using with 2.10.1.  I wasn't able to finish porting them to 2.10.91 so far
and I am going to work on them over the weekend.  Hopefully you'll agree
to integrate them into the 2.11 release as well, especially as all of them
are fixes and not new features. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: next release

[Philip Blundell]

> I've sent the patches I was able to integrate so far.  All of them were
>previously sent to the list and didn't get applied either with no comment
>whatsoever or they just got lost after a positive reply (in the Ian's
>days). 

Thanks for sending these again.  Since there are a few others outstanding as 
well, I've decided to hold off on making the branch for a few days.  Let's 
re-assess the situation early next week, say on Tuesday; that might give you 
time to finish up your other changes too.

p.

Re: next release

[Jakub Jelinek]

Can anyone approve
http://sources.redhat.com/ml/binutils/2000-12/msg00328.html
or tell me what's wrong with it? Basically, readelf either does not work at
all with symbol versioning (if first vma is large) or shows wrong
information from time to time (even with first vma 0).

	Jakub

Re: next release

[Alan Modra]

On Sat, 20 Jan 2001, Jakub Jelinek wrote:

> Can anyone approve
> http://sources.redhat.com/ml/binutils/2000-12/msg00328.html
> or tell me what's wrong with it? Basically, readelf either does not work at
> all with symbol versioning (if first vma is large) or shows wrong
> information from time to time (even with first vma 0).

I noticed an inconsistency in the code printing verdefs.  The code you
trimmed out used

			  GET_DATA (offset + ivd.vd_aux, evda,
				    "version definition aux");

while the code left in uses

		      GET_DATA (offset - ivd.vd_next + ivd.vd_aux,
				evda, "version def aux");

It looks to me you chose the correct one, but please double check this,
then check it in.

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: next release

[Jakub Jelinek]

On Wed, Jan 24, 2001 at 12:00:05AM +1100, Alan Modra wrote:
> On Sat, 20 Jan 2001, Jakub Jelinek wrote:
> 
> > Can anyone approve
> > http://sources.redhat.com/ml/binutils/2000-12/msg00328.html
> > or tell me what's wrong with it? Basically, readelf either does not work at
> > all with symbol versioning (if first vma is large) or shows wrong
> > information from time to time (even with first vma 0).
> 
> I noticed an inconsistency in the code printing verdefs.  The code you
> trimmed out used
> 
> 			  GET_DATA (offset + ivd.vd_aux, evda,
> 				    "version definition aux");
> 
> while the code left in uses
> 
> 		      GET_DATA (offset - ivd.vd_next + ivd.vd_aux,
> 				evda, "version def aux");
> 
> It looks to me you chose the correct one, but please double check this,
> then check it in.

The latter is correct (offset is incremented by ivd.vd_next in between) and
I think this is the reason why old readelf -a generates different result
than readelf -a with this patch:

The diff between the two outputs contains stuff like:
@@ -9935,7 +9936,7 @@ Version symbols section '.gnu.version' c
   038:   0 (*local*)       0 (*local*)       0 (*local*)       0 (*local*)
   03c:   0 (*local*)       0 (*local*)       7 (GLIBC_2.2)     2 (GLIBC_2.0)
   040:   2 (GLIBC_2.0)     2 (GLIBC_2.0)     2 (GLIBC_2.0)     2 (GLIBC_2.0)
-  044:   2 (GLIBC_2.0)     2 (GLIBC_2.1)     2 (GLIBC_2.0)     2 (GLIBC_2.0)
+  044:   2 (GLIBC_2.0)     2 (GLIBC_2.0)     2 (GLIBC_2.0)     2 (GLIBC_2.0)
   048:   3 (GLIBC_2.1)     3 (GLIBC_2.1)     2 (GLIBC_2.0)     2 (GLIBC_2.0)
   04c:   7 (GLIBC_2.2)     2 (GLIBC_2.0)     6 (GLIBC_2.1.3)   3 (GLIBC_2.1)
   050:   2 (GLIBC_2.0)     2 (GLIBC_2.0)     2 (GLIBC_2.0)     2 (GLIBC_2.0)
...

(- is readelf without this patch, + with that patch).

	Jakub

Re: next release

[Maciej W. Rozycki]

On Sat, 20 Jan 2001, Philip Blundell wrote:

> Thanks for sending these again.  Since there are a few others outstanding as 
> well, I've decided to hold off on making the branch for a few days.  Let's 
> re-assess the situation early next week, say on Tuesday; that might give you 
> time to finish up your other changes too.

 OK, I've sent almost all patches I consider for 2.11.  The remaining one
was created by Ulf Carlsson in the 2.9.5 days.  Much of his code got
incorporated into 2.10.91.  I've sent him the remaining bits for a
comment.  I'm not sure if they are needed for MIPS/Linux -- I haven't
tested such a configuration.  They are needed for MIPS64/Linux and for
some SGI configurations, AFAICS.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

next release

[Philip Blundell]

So, it's that time again when thoughts inevitably turn to a new version of 
GNU binutils.  I'd like to aim for a release at the start of March, with a 
freeze at the end of January.  

If you're sitting on patches for new ports or other features, the next few 
weeks are the ideal time to dust 'em off and send 'em in.  If you're working 
on something that you'd like to be included, but you aren't sure it will be 
ready in time, let me know.

Please test your favourite targets and make sure they are in tip-top condition.  
If you know of bugs, or missing functionality, speak out now.

Thanks

p.

Re: next release

[Hans-Peter Nilsson]

> Date: Wed, 27 Dec 2000 10:45:28 +0000
> From: Philip Blundell <philb@gnu.org>

> If you're sitting on patches for new ports or other features, the next few 
> weeks are the ideal time to dust 'em off and send 'em in.  If you're working 
> on something that you'd like to be included, but you aren't sure it will be 
> ready in time, let me know.

You're thinking of a new *major* release, right?

Mostly for a minor release, please consider
<URL: http://sources.redhat.com/ml/binutils/2000-12/msg00098.html >.

Or we should not use AM_PROG_LEX but instead some local
AM_BINUTILS_PROG_LEX where the bug is fixed.  Hmm.

brgds, H-P

Re: next release

[Philip Blundell]

>You're thinking of a new *major* release, right?

Yes.  I don't think it would be worthwhile to make another minor release from 
the 2.10 branch at this point.

p.

Re: next release

[David O'Brien]

On Wed, Dec 27, 2000 at 05:33:30PM +0000, Philip Blundell wrote:
> >You're thinking of a new *major* release, right?
> 
> Yes.  I don't think it would be worthwhile to make another minor
> release from the 2.10 branch at this point.

From FreeBSD's point, I agree.  2.10.0 was a god-send, and I was very
happy to see 2.10.1 released to fix some nits.  At this point, FreeBSD's
assembler and linker needs are being well met by the GNU Binutils team.
Thank you!!  :-)))

-- 
-- David  (obrien@FreeBSD.org)

Re: next release

[Alexandre Oliva]

On Dec 27, 2000, Hans-Peter Nilsson <hans-peter.nilsson@axis.com> wrote:

> Or we should not use AM_PROG_LEX but instead some local
> AM_BINUTILS_PROG_LEX where the bug is fixed.  Hmm.

Or just copy the fixed definition of AM_PROG_LEX to acinclude.m4.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me