[OE-core] [PATCH 1/7] binutils: upgrade from 2.21 to 2.21.1

[Richard Purdie]

On Thu, 2011-07-07 at 17:42 -0700, Khem Raj wrote:
> 
> On Jul 7, 2011, at 4:12 PM, Richard Purdie <richard.purdie at linuxfoundation.org> wrote:
> 
> > On Thu, 2011-07-07 at 14:39 -0700, Khem Raj wrote:
> >> On Thu, Jul 7, 2011 at 1:25 PM,  <nitin.a.kamble at intel.com> wrote:
> >>> From: Nitin A Kamble <nitin.a.kamble at intel.com>
> >>> 
> >>> Signed-off-by: Nitin A Kamble <nitin.a.kamble at intel.com>
> >>> ---
> >>> ...n_2.21.bb => binutils-cross-canadian_2.21.1.bb} |    0
> >>> ...tils-cross_2.21.bb => binutils-cross_2.21.1.bb} |    0
> >>> ...rosssdk_2.21.bb => binutils-crosssdk_2.21.1.bb} |    0
> >>> .../110-arm-eabi-conf.patch                        |    0
> >>> .../binutils-2.19.1-ld-sysroot.patch               |    0
> >>> .../binutils-poison.patch                          |    0
> >>> .../binutils-pr12366.patch                         |    0
> >>> .../binutils-uclibc-100-uclibc-conf.patch          |    0
> >>> ...binutils-uclibc-300-001_ld_makefile_patch.patch |    0
> >>> ...binutils-uclibc-300-006_better_file_error.patch |    0
> >>> ...ils-uclibc-300-012_check_ldrunpath_length.patch |    0
> >>> .../binutils-uclibc-gas-needs-libm.patch           |    0
> >>> .../binutils-x86_64_i386_biarch.patch              |    0
> >>> .../libiberty_path_fix.patch                       |    0
> >>> .../libtool-2.4-update.patch                       | 1725 ++++++++++----------
> >>> .../libtool-rpath-fix.patch                        |    0
> >>> .../{binutils_2.21.bb => binutils_2.21.1.bb}       |    7 +-
> >>> 17 files changed, 871 insertions(+), 861 deletions(-)
> >>> rename meta/recipes-devtools/binutils/{binutils-cross-canadian_2.21.bb => binutils-cross-canadian_2.21.1.bb} (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-cross_2.21.bb => binutils-cross_2.21.1.bb} (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-crosssdk_2.21.bb => binutils-crosssdk_2.21.1.bb} (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/110-arm-eabi-conf.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-2.19.1-ld-sysroot.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-poison.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-pr12366.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-uclibc-100-uclibc-conf.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-uclibc-300-001_ld_makefile_patch.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-uclibc-300-006_better_file_error.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-uclibc-300-012_check_ldrunpath_length.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-uclibc-gas-needs-libm.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-x86_64_i386_biarch.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/libiberty_path_fix.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/libtool-2.4-update.patch (94%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/libtool-rpath-fix.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils_2.21.bb => binutils_2.21.1.bb} (87%)
> >>> 
> >> 
> >> How about changing the recipe to fetch from binutils-2_21-branch and
> >> call it binutils 2.21 as it is
> > 
> > I don't really see the benefits in fetching this from the SCM?
> 
> Not much yes however
> 
> Releases happen not so frequently but bug fixes go into the branch and
> it makes it easier to upgrade may be same as adding patches to
> metadata but we don't need to keep them local in metadata
> 
> It will match the process we do for other toolchain components

I have a dislike for depending on what are usually slow SCMs for
components of the system. I've been convinced we need to do it for gcc
but I think that is the exception to the rule and we don't have a
seriously large number of patches queued against binutils...

I've therefore taken the patch.

Cheers,

Richard