valgrind: Add glibc 2.19 awareness

It wont compile otherwise and fail with errors e.g.

Valgrind requires glibc version 2.2 - 2.17 ...

Signed-off-by: Khem Raj <raj.khem@gmail.com>
eglibc: Upgrade from 2.18 -> 2.19

License formatting and address for FSF in the COPYING and COPYING.LIB
has changed.

Dropped patched already upstream and patches that were workarounds for
older glibc and busybox

for e500 we have should pass --without-fp to eglibc/glibc 2.19 onwards
the code is merged from eglibc into glibc upstream under nofpu/ pretext

Signed-off-by: Khem Raj <raj.khem@gmail.com>
rootfs.py: Check for LDCONFIGDEPEND being empty string

We override LDCONFIGDEPEND to be empty string for uclibc
however the current check is for it being None as a result
the function is still executed but ldconfig-native is not
built as dependency for rootfs when building with uclibc

Fixes errors like below

File:
'/home/kraj/work/angstrom-repo/sources/openembedded-core/meta/lib/oe/rootfs.py',
lineno: 191, function: _run_ldconfig
     0187:    def _run_ldconfig(self):
     0188:        if self.d.getVar('LDCONFIGDEPEND', True) is not None:
     0189:            bb.note("Executing: ldconfig -r" +
self.image_rootfs + "-c new -v")
     0190:            self._exec_shell_cmd(['ldconfig', '-r',
self.image_rootfs, '-c',
 *** 0191:                                  'new', '-v'])

Signed-off-by: Khem Raj <raj.khem@gmail.com>
icu: Disable the default LDFLAGSICUDT for target compile

By default LDFLAGSICUDT=-nodefaultlibs -nostdlib for Linux
which means DT_NEEDED section for libicu will not be populated
with dependencies when we reset it to be empty then the default
libraries it needs are added to DT_NEEDED section in ELF header

This patch is a workaround as I consider it for now, since it could
be a problem in glibc dynamic loader for arm (especially for hf case)
where its unable to load shared objects which dont have any dependencies
expressed in DT_NEEDED segment.

here is when LDFLAGSICUDT=-nodefaultlibs -nostdlib

Dynamic section at offset 0x1549c10 contains 8 entries:
  Tag        Type                         Name/Value
 0x0000000e (SONAME)                     Library soname:
[libicudata.so.51]
 0x00000010 (SYMBOLIC)                   0x0
 0x6ffffef5 (GNU_HASH)                   0xf8
 0x00000005 (STRTAB)                     0x188
 0x00000006 (SYMTAB)                     0x138
 0x0000000a (STRSZ)                      54 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000000 (NULL)                       0x0

here is one with LDFLAGSICUDT empty

Dynamic section at offset 0x154a014 contains 22 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000e (SONAME)                     Library soname:
[libicudata.so.51]
 0x00000010 (SYMBOLIC)                   0x0
 0x0000000c (INIT)                       0x33c
 0x0000000d (FINI)                       0x500
 0x6ffffef5 (GNU_HASH)                   0xf8
 0x00000005 (STRTAB)                     0x204
 0x00000006 (SYMTAB)                     0x144
 0x0000000a (STRSZ)                      192 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000003 (PLTGOT)                     0x154a0f8
 0x00000002 (PLTRELSZ)                   16 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x32c
 0x00000011 (REL)                        0x2fc
 0x00000012 (RELSZ)                      48 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffe (VERNEED)                    0x2dc
 0x6fffffff (VERNEEDNUM)                 1
 0x6ffffff0 (VERSYM)                     0x2c4
 0x6ffffffa (RELCOUNT)                   1
 0x00000000 (NULL)                       0x0

btw. ldd reveals the fist one to be static library while the second
one is detected as shared library. This could be a clue into how
elf headers are being interpreted by dynamic loader.

The data seems to be all static in libicudata which could
load it quicker and thats what could be confusing dynamic linker ..may
be

Signed-off-by: Khem Raj <raj.khem@gmail.com>
binutils: ld-is-gold should not affect native and crosssdk recipes

gold linker does not support all architectures, currently arm and x86
are best supported, therefore we can not enable this as a full distro
option where we need to support other architectures e.g. ppc, mips
currently, if we enable ld-is-gold distro feature conditionally then it
invalidates native and sdk version of native binutils because configure
option would change. With this patch we limit ld-is-gold feature to
imapact cross binutils and target binutils only. This means that we
can reuse the sdk and native versions across architectures.

Signed-off-by: Khem Raj <raj.khem@gmail.com>
uclibc: Update to git tip

Signed-off-by: Khem Raj <raj.khem@gmail.com>
image_types.bbclass: Fix tar IMAGE_CMD to not change directories

below commit

commit 9d9bca8785911e8ae06d507bbfb99d6a811f072e
Author: Jonathan Liu <net147@gmail.com>
Date:   Mon Feb 17 21:46:28 2014 +1100

    lib/oe/image.py: fix working directory

    The working directory needs to be changed before the image creation
    commands instead of afterwards.

exposed an issue when generating tar images, where it would cd into
rootfs and then create the rootfs tarball and remain there since the
cmd to cd into deploy dir moved up the immediate following cmd like
tar.bz2 or tar.gz were still looking for tarball in current directory
which esentially was not deploy dir but IMAGE_ROOTFS instead

Signed-off-by: Khem Raj <raj.khem@gmail.com>