Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

["Maciej W. Rozycki" <macro@linux-mips.org>]

On Tue, 26 Oct 2010, H. Peter Anvin wrote:

> >  Also note that *.*.9x versions are snapshots from the FSF repository (so 
> > there's no fixed date associated with them), which also delegates 
> > maintenance responsibility to whoever packages them and makes available to 
> > people.  In the state as imported from the repository they may have odd 
> > problems or grave bugs, as exhaustive regression testing is generally only 
> > made after a release branch has been created and otherwise changes to the 
> > head of the tree are only tested for a limited subset of targets before 
> > they are applied.  Therefore local fixes are inevitable for them anyway.
> 
> Well, sort of... the x.x.9x releases used in production -- specifically
> the ones with a numbering scheme like x.x.9x.0.x -- in the Linux world
> tend to be the ones maintained and released by H.J. Lu:
> 
> http://www.kernel.org/pub/linux/devel/binutils/

 Yeah, in practice this means the packagers have an additional choice to 
pester H.J. if something goes wrong. ;)

 I used H.J.'s releases once too, then around 2.9.4 I switched over to 
pristine FSF sources as I figured out I needed to make own fixes for the 
MIPS port and it was easier for me to propagate them upstream this way.  
And overall I found no problems (apart from the usual bugs here and there 
every once in a while) having since used them for the Alpha, MIPS, VAX and 
x86 ports of Linux (OK, perhaps x86 is not a port ;) ), so the choice 
between the two flavours is mostly the matter of taste it would seem.

> >  And last but not least binutils are one of the easier tools to build from 
> > sources, so installing a newer version, especially when it comes to native 
> > tools (hardly anyone uses cross-compilation targeting x86, I believe), 
> > somewhere under $HOME to use for kernel builds is a trivial effort:
> > 
> > $ ./configure --prefix=$HOME/somewhere && make && make install
> > $ PATH=$HOME/somewhere/bin:$PATH
> > 
> > Certainly much easier than building the kernel, especially when it comes 
> > to selecting the right configuration options.
> 
> Yes, although there is also a version dependency between binutils and
> gcc, as I unhappily found out trying to run an upversion gcc on an old
> distro at one point.

 Fair enough if you do it this way, but switching to a higher version of 
binutils shouldn't ever be a problem.  GCC detects some binutils features 
at the configuration time and sets itself up accordingly, but these do not 
get removed, at least not that I heard of.

  Maciej