Next release

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Next release

Daniel Jacobowitz-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Next release

NightStrike
On 6/27/08, Daniel Jacobowitz <[hidden email]> 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 :)
Reply | Threaded
Open this post in threaded view
|

Re: Next release

Tristan Gingold-2
In reply to this post by Daniel Jacobowitz-2
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Next release

Aaron W. LaFramboise
In reply to this post by Daniel Jacobowitz-2
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.

Reply | Threaded
Open this post in threaded view
|

Re: Next release

Daniel Jacobowitz-2
In reply to this post by Daniel Jacobowitz-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Next release

Tristan Gingold-2
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
>

Reply | Threaded
Open this post in threaded view
|

RE: Next release

Weddington, Eric-2
 

> -----Original Message-----
> From: Tristan Gingold [mailto:[hidden email]]
> Sent: Thursday, August 14, 2008 2:44 AM
> To: [hidden email]
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Next release

David Daney
Weddington, Eric wrote:

>  
>
>> -----Original Message-----
>> From: Tristan Gingold [mailto:[hidden email]]
>> Sent: Thursday, August 14, 2008 2:44 AM
>> To: [hidden email]
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Next release

David Miller-13
From: David Daney <[hidden email]>
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.
Reply | Threaded
Open this post in threaded view
|

Re: Next release

Brian Dessent
In reply to this post by David Daney
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
Reply | Threaded
Open this post in threaded view
|

Re: Next release

NightStrike
In reply to this post by David Miller-13
On 8/15/08, David Miller <[hidden email]> wrote:

> From: David Daney <[hidden email]>
> 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.
Reply | Threaded
Open this post in threaded view
|

RE: Next release

Weddington, Eric-2
In reply to this post by Brian Dessent
 

> -----Original Message-----
> From: Brian Dessent [mailto:[hidden email]]
> Sent: Friday, August 15, 2008 3:44 PM
> To: David Daney
> Cc: Weddington, Eric; Tristan Gingold;
> [hidden email]; 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...
Reply | Threaded
Open this post in threaded view
|

RE: Next release

Weddington, Eric-2
In reply to this post by Brian Dessent
 

> I was intimating that binutils would, perhaps, benefit from
> being tied to gcc's release schedule one two fronts: one, it
---------------------------------------^
"on two fronts:"
Reply | Threaded
Open this post in threaded view
|

Re: Next release

Brian Dessent
In reply to this post by Weddington, Eric-2
"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
Reply | Threaded
Open this post in threaded view
|

Re: Next release

Daniel Jacobowitz-2
In reply to this post by Tristan Gingold-2
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

checklist.txt (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Next release

Tristan Gingold-2

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.


Reply | Threaded
Open this post in threaded view
|

Re: Next release

Daniel Jacobowitz-2
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