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 -- 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
