On 10/26/2010 03:53 AM, Maciej W. Rozycki 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/ > 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. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
